👀👀👀👀
Discussion
What's the goal?
I guess. Provide a link to a mint on nostr profile. So you can use the mints of your trusted nostr plebs.
It signifies which mints I trust so if you're going to send me ecash, I'd prefer it to be from one of those mints.
this is also exactly the same issue that exists with mailboxes and NIP-65 is about this, nostrudel implements this feature and it should be moved to a more mandatory status IMO
mailboxes and mints are the same exact type of protocol
That’s a bad place to place them; do a new kind; it’s going to make so much easier for everyone 😅
Could you elaborate? We're still actively discussing on how one would approach this best. Why not here?
* makes it really hard to discover what mints people are using
(if it were it's own kind you can query the minds and see what other people are using instead of inspecting one-by-one kind:0s)
* kind:0 getting all these magic strings with different meanings is an anti-pattern
* you are all but guaranteed that some app will destroy this information accidentally
I hear you.
1) we don't want to do this for discovery. They should serve the same purpose as a lightning address in your profile does.
2) is that profile JSON precisely defined anywhere? I see a lot of mess in profiles and it seems to be ok?
3) yeah that's true but that seems to be a bigger issue. No app should just overwrite fields like that, right?
last point is key
i told nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that deleting events for replacement is racy, and maybe people are starting to get the idea now... they should keep a history and prune them preferentially when looking to free up storage
just to explain how it's racy: it can happen that one moment my data set has a certain state, and because i send out a delete event, some relays will delete it, where some will just return the newest one and let you get the old one (this is common on some relays but not others)
there should be a stipulation in the replaceable events (both kinds) that they are preferably not actually deleted but multiple can be returned from a filter and then the client can filter through them and find the field they are looking for in a recent version
not deleting things and adding a "replaces" tag would fix all this problem altogether
it will take time for it to get rolled out but i think the number of times i have heard people talking about having their profile get nuked because it's a replaceable event i have definitely lost count
Clients that don’t support your new format may overwrite kind 0s without the new field anytime a user updates their profile. A separate kind is a better way to insure nobody “messes” with it by accident.
Clients shouldn't override extra fields though, that's bad implementation.
Yeah that sounds like clients who do this are broken.
There is should and there is reality.
Yeah totally. My lightning address and other profile data were never overwritten since I started using nostr though.
True but I think most clients implement zaps so that’s a field they all care about.
We certainly have this overwriting problem with kind 3s.
Part of the problem is the kind 0 spec is scattered over a ton of NIPs. There is NIP-01, NIP-24, NIP-57, and I imagine others that reference profile fields but can’t find anywhere to see them all in one place.
…with that being said, I totally understand why you want to put it in kind 0 and I don’t think it’s the end of the world. Just might face some challenges until it’s more widely adopted.
not really, an event is an event
this is a general problem with the implementations at present, replaceable events cause previous versions to be deleted by relays and what they SHOULD be doing is just returning newest ones and allowing clients to request older versions
i've made an issue about this and nobody is really taking it seriously at this point
I'm on team "replaceable events are bad". nostr:nprofile1qywhwumn8ghj7mn0wd68ytndw46xjmnewaskcmr9wshxxmmd9uq3qamnwvaz7tmwdaehgu3wd4hk6tcpz4mhxue69uhkummnw3ezummcw3ezuer9wchsqgzsm98u9kzcp35zkpc62shck8335gqtq5yt4w26xwl0pp2a72qavvkw9mkh race conditions frequently happen regardless of client implementation, where a stale version forms the basis for an update. The more attributes on kind 3, the more potential for race conditions.
PLEASE
When a sat is minted and then signed into eCash, does the recipient of that eCash need to have the very same mint added in order to receive?