I’m sorry yall, I realise now how spammy it looks esp. because I have a new account.
I’m Hessel, 25yo, living in Amsterdam, the Netherlands. I currently have an xNT in my right hand, used it a lot at my study association where we have a vending machine that you could link your own rfid card to, so of course I linked my xNT. Worked very well for a long time, but I don’t study there anymore.
Unfortunately for a lot of purposes the xNT’s antenna is just too small, so I’m definitely interested in getting a different one with a bigger antenna, especially if it comes with contactless payment possibilities!
I understand that it’s not an issue with the banks themself, but if we get enough banks to push/approach visa/mastercard, I guess they’ll at least start thinking about it more seriously.
I wish that kind of mindset was something crawling out of Lovecraftian immagination… but then I remember people burning down 5G towers (most were not even 5G) to “stop the spread of covid”…
Although…
Technically, we kinda missed a golden opportunity to do exactly that.
Albeit with less cool explosions, and more demand acknowledgement.
Right when small shops and delivery folks begun to grow, they needed a mobile payment option, and there was none. Visa and Mastercard jumped in with remote readers, but that was a golden opportunity to get cryptocurrencies to find their spot in regular market.
Maybe there is still a chance. If we could:
Simplify the transition between “real” money and crypto
provide an easier and easily widespread way of taking payments (talking mobile apps here)
provide people with an easy, trustworthy means of utilising this new network (again, mobile apps acting like passive tags… and implants/cards alike)
Then all you need is a good publicity stunt.
People dream of paying just by tapping a phone onto another phone.
Maybe all we really need to do is address the UX gaps within the currently monopolized systems.
(and then, resist the temptation to get corrupted ourselves… but hey, Palahniuk is there for it!)
When conversion is done and you receive the implant, make an appointment with a professional body modification artist, I recommend Tom van Oudenaarden from Piercing Studio Utrecht.
It took about 7 seconds to write on my Pixel 2 and about 6 seconds to read it all. Using FASTREAD command support this should be much shorter, but I realized from my previous discovery about how Android handles NFC data that the phone is basically trying to read the whole damn NDEF record BEFORE it passes NFC control to the app, which then reads the whole damn thing again. I have no idea why Android is doing this stupid crap but it does and there is no way around this… so basically reads will take twice as long as they should.
Shall I enable 32k NDEF containers? This is where things broke last time… but I feel like the P71 can handle it.
I believe that’s just the intent mechanism. I quickly looked at the relevant Android code a while ago, and it’s clear that normally, Android is supposed to get out of the way when the app in focus wants to deal with NFC all on its own. But I’m assuming there are certain types of NFC intents that can override the app in focus. So Android has to know what’s on the chip as well as the app. Possibly?
Either that or - more likely - whoever coded the NFC intent mechanism figured it was so quick he could leave the default code running all the time and nobody would notice
has to be set in the chip at NXP (factory) during manufacturing of the silicon chip itself… and these will be… and the chip will be able to load and run EMV applications (for payment) and secure apps that use advanced crypto at the same time. The EMV applets are loaded by NXP during silicon manufacture, but the other applets you can deploy to the chip with your phone and the Fidesmo mobile app.
absolutely… each javacard application has a unique AID (application ID) which is “selected” by the reader and the code is run on chip. you can fit as many applications on as will fit in the memory.
I admit being too lazy to read through android docs (I developed an intense hatred over java, and Kotlin ain’t cute enough to balance it)…
But my money goes to how the libs are structured, mostly around the checks done to detect the presence of NDEF capabilities. What some libs do is to attempt and read a message, if you can’t, then there isn’t. If you can, then you already have it read.
(the whole “better ask for forgiveness” mindset)
In some libs, such as nfcpy, you have direct calls for that, which work well since that’s the paradigm you want. so you only check for the presence if you want to read it.
Now applying Android logic, whenever anything within Android finds something new, it must consume it to check if anything else was expecting you to find it (hope my layman’s version of “Intent” wasn’t too confusing), but then if your application has not told the system it wanted that piece of information yet, then it gets discarded, and the only thing that gets through is “yes, there is an NDEF message”, which then your code will open (and read again)
ps: as of the moment, this is but an educated guess I put together in the midst of assumptions and recollections. I really don’t want to go digging into Java source…
