Last Call:
Wanted to bump this og thread and see of anyone here have specific NDEF features you’d like in ChipVault. We are just about to feature freeze this set before our dev kicks off.
Stupid question, what features are we talking about? Like, url, phone, open an app?
Not a stupid question - thanks for asking.
Yep, table stakes: including contact object, wifi pwd, etc. Just trying to gauge what most people want out of this. We plan to go w/ bare min. But, open to hearing requests for prioritization.
If I can add my rick roll url, I’m happy ![]()
Sorry buddy,
to answer your question, yes.
I just needed to “put pen to paper”
My list / request is far from that, I have simply listed some common ones.
THE LIST
(Some of these could be combined reduce the total number)
I actually combined the
TITLE
Subtitle into catergories which reduced the list significantly 24 → 7
THE NEW LIST
TEXT
Add a text record
LINK
URL, URI, URN, Custom URL, DropBox, Search, Social networks, Video, File, Application, Mail, Bitcoin
CONTACT
Contact, Phone number, SMS
LOCATION
Google Maps, Waze, Apple Maps, What3Words, Custom location, Address, Destination address, Proximity search, Street View
EMERGENCY
ICE (Information in case of emergency)
CONNECTIVITY
Bluetooth, Wi-Fi network
DATA
Add a custom record
Thoughts?
Too many?
Actually… ![]()
Maybe 8 categories
If we move Bitcoin into
CRYPTO
Bitcoin, Ethereum, Tether, Solana, Cronos etc
Okay 9…
LAUNCH APPLICATION
add app to launch on tap
Obviously each sub category will need a page to complete, but some of those will be the same
What I could do, is create a poll so people can choose their favourites?
Is this for a cleaner UI?
or is it a space consideration for App size or card memory?
The UI
Having the catergories and drill down menu will help with that? keeping it clean?
NDEF →
9 categories
If for card space, the data will be on the App until written, so these extra NDEF options wont affect the card memory until written.
Also
I am asking a question here, not questioning your decisions…
I see in the Current app at the moment, you have set memory containers.
Wouldn’t this be better if people had the freedom to add what they wanted and as much / little as they liked rather than restricted or wasted storage?
for example
In my medical container above, I have 18 B wasted / unusable
or
the other way of looking at it.
If I wanted to add more data, I am limited to only adding 18 B more.
Not shitting on the app, I really like it, just some constructive comments and questions…
@Pilgrimsmaster - a poll would be great if you’re able to initiate please. Thank you - sincerely appreciated! Your above list is much appreciated. A few of these are already in our roster.
Thanks for asking this question about storage; btw, it’s separate from the NDEF topic, however, no worries there. Let’s address your questions here.
You’re right that today each category gets a fixed, equal-sized container, and space left in one can’t spill into another. The reason is security: on these cards each category is a separate encrypted area with its own key, so one category can’t read into another’s space — that isolation is core to how ChipVault protects your data. Additionally, the hardware requires each area’s size to be set when the card is first set up, which is why the space is divided up front rather than growing on demand.
One thing that helps today: the space is split evenly across the categories you enroll, so setting up a card with fewer categories gives each one more room. If Medical is your heaviest, a card with just the categories you actually use will give it a bigger share.
We have a back-log entry for letting users give specific categories more room than others — as a feature request for us to consider down the road (no promises on timing).
And separately, your card looks like it may have been set up on an earlier version that allocated less per category than current cards do. If you tell me your app version and card type, we will be happy to check whether re-setting-up the card would give you meaningfully more room.
Really appreciate you taking the time in sharing this feedback.
Ahh, that makes sense.
Version
1.3.0 (build 13)
I can most certainly do this, I am away from home and PC at the moment (a large poll will be much easier and faster on a PC)
I will have time to decide the best way to build the poll.
Wheteher or not I just go for categories or include the subcategories or build a seperate poll for each category ![]()
Let’s make a Poll with fewer than 10 options
( I have broken it down into Categories and you can vote for UPTO 9 choices )
What options would you like to see in ChipVault as NDEF options
- TEXT - Add a text record
- LINK - URL, URI, URN, Custom URL, DropBox, Search, Social networks, Video, File, Application, Mail
- CONTACT - Contact, Phone number, SMS
- LOCATION - Google Maps, Waze, Apple Maps, What3Words, Plus Codes, Custom location
- EMERGENCY - ICE (Information in case of emergency)
- CONNECTIVITY - Bluetooth, Wi-Fi network
- DATA - Add a custom record
- CRYPTO - Bitcoin, Ethereum, Tether, Solana, Cronos, USDT etc
- LAUNCH APPLICATION - add app to launch on tap
If you don’t have ChipVault yet, and wan’t to try it
Android
iPhone
Thanks — that confirms it. 1.3.0 (build 13) is the current version, so you’re fully up to date.
In further looking, there are two separate things going on here, so let me split them:
1) The “nearly full” look — this is a display bug, and it gets fixed in the next release. Nothing for you to do.
The “System overhead — 7,072 B / 9% free” readout is misleading: it’s counting your unallocated space as overhead. In reality only ~1.3K is true overhead, so roughly half your card is actually free. We just confirmed this on our end and it’s queued for the next release — once you update, the numbers will show correctly on their own.
2) The 160 bytes per category — this is real, and it only changes by re-setting-up the card. Here’s exactly how.
Each category’s size is locked onto the card when it’s first set up (yours is 160 B, from an earlier setup), and the update in #1 won’t change that — it only fixes the display. If you want more room in a category (your Medical is at 142/160), re-setting-up re-allocates it much larger — keeping all seven categories, each jumps to ~672 B; with fewer categories, more each. Since 1.3.0 added Export/Import, you won’t lose anything:
- Export Card Data — tap the card to read it, set a password, and save the backup file somewhere off-device (Files, Drive, etc.).
- Reset Card to Factory — this wipes the card so it can be re-sized.
- Set up the card again — keep the same seven categories so your backup restores cleanly (or pick fewer if you want even more room per category).
- Import Card Data → Restore to this card — choose your backup file, enter the password, and tap the card. Your entries come back into the larger categories.
Back up first (step 1) and keep that file until you’ve confirmed the restore looks right. One caveat: if you set up with fewer categories than you backed up, only the matching ones restore automatically — so if you’re keeping all your data, keep the same seven.
Appreciate you flagging this — the display fix in #1 genuinely came out of your screenshot.
New version of ChipVault released for iOS and Android - parity matched.
What’s New:
Public Record (NDEF). Give any DESFire card a tappable link or contact card — any NFC phone reads it on a tap, no app needed. Your private vaults stay AES-128 encrypted. Now on iPhone + Android, full feature parity.
My version is 1.4.0 which was released 2 days ago, Is that correct.
There is no further update avaliable.
I need to have more of a play, because o have been having a problem with one of my test cards. It seems to be locked, and I couldn’t unlock it, my trail version of the app has ended, I’ll grab the paid one tomorrow and try again
New version of ChipVault released for iOS and Android - parity matched.
What’s New:
Public Record (NDEF). Give any DESFire card a tappable link or contact card — any NFC phone reads it on a tap, no app needed. Your private vaults stay AES-128 encrypted. Now on iPhone + Android, full feature parity.
That’s the most latest ver of the Android ChipVault
One NDEF feature request from the boring end of the use case list: a “write and verify” mode that reads the record straight back off the tag and shows a diff before it reports success. Most write failures I’ve seen on implants aren’t clean errors, they’re partial writes from the phone drifting mid-transaction, and the app reports success because the write call returned. A read-back check turns that into a visible failure instead of a tag you find out about later at a door.
Second, please allow saving a named NDEF payload as a reusable template locally, so re-writing a chip after experimenting doesn’t mean retyping a URI or a text record by hand. Bonus if templates can be exported as plain files, so people can keep them in whatever notes system they already use rather than trapped in the app.
Third, on the record type side: an explicit warning when a payload will exceed the tag’s usable capacity, calculated before the write rather than after truncation. Capacity maths differs enough between chip types that people guess wrong, and truncated URIs fail in confusing ways.
Smaller thing: if you add multi-record support, show the record order and let it be reordered, since the first record is what most phones act on. That ordering behaviour is unobvious to anyone who hasn’t read the spec.
