Open amark opened 4 years ago
@amark not sure i understand, can you give an example of an issue/bug? as long as these properties are not necessary for the gun.user() functionality why do we care?
I don't think there's much of a problem in the case of Iris. It automatically saves the epub for new users.
The only problem arises when you scan someone's chat link offline and try to send them a message: doesn't work, because chat links contain only pub and not epub. Two solutions: 1) Save and encrypt the messages to yourself first and later to the actual recipient when you get their epub. That adds a bit of complexity. 2) Add epub to chat links. Simple and efficient, but makes the chat links annoyingly long. That could be alleviated if gun.user() accepted a shorter alias (key ID) instead of pub.
if I understand correctly, a possible issue is that user doing login using auth(keys) can't be found by other users? pub is the id of the user and epub is the public key? dont we already have an index by "~pub"? if not why not make auth(keys) add user ~pub just like login does?
@amark I still seemed to be able to do gun.get('~pub').get('epub).once(console.log). Obviously it would be nice this was always available, but depending on the throwaway key (and it's usage) you only need the encryption keys anyways.... soooo not sure
@amark also i'm not sure i understand the "throw away key". usually the app owner will make sure the user keep his key somewhere... ie localstorage/securestorage and ask him to back it up What's the use case for throw away key? in general there's a bloat issue with gun as there's basically no delete so i think that's a separate issue.
@thrownness @sirpy @mmalmi @Dletta @JamieRez + whoever else, should be aware of this!
Standard practice is to load the
epub
off the account (since you know itspub
) to do then secret derivation with...But the account may not have any default data saved to it!!!
What do you recommend as fix? Have SEA's User system check each time key-based login, do an exists check to see if these properties exist, and then save them? This would mean User system is doing automatic "magic" every time that may make network dependent calls. Or, do we just say (in docs) "screw it, you made throw away keys, you gotta manage it!" (cause note: if people do make tons of throwaway keys, each throwaway login is gonna attempt to save/store/sync these default properties, which will accumulate). So screw it or magic?
There is also the weird thing that these accounts accidentally attach their keys to
user.is.alias
(or something similar) which is not good.