hodlbod

> for relays that have not implemented the "AUTH" verb, what use case do claims have? None, I had originally used a new `JOIN` verb, should have explained that. @fiatjaf...

It actually adds a lot of complexity. Auth is invalid if there is no claim, and no challenge, but it can be valid if either is valid, but what if...

That's something that happens anyway when requesting DMs etc for a particular user, auth is triggered based on event inspection.

> requesting DMs would use "REQ" message, not "EVENT" message. Right, confused myself, but the same is true about selectively accepting events. > using new event kind with "AUTH" message...

Interesting. I suppose that doesn't seem any worse than anything else, but I don't think we can assume that relays will handle a new event kind properly. @fiatjaf told me,...

You're saying the DVM would be *in* the relay? I like that a lot.

It seems simpler, but you're really creating an unspecified sub-protocol nested inside chat. Which, if it's to be interoperable, needs to be specified anyway. So we may as well specify...

UTC keeps logic much simpler, timezones are a nightmare. Human readable would be nice, but an int is more compact, and can be used without a library. I think it's...

It might be a good idea to model this as closely as is reasonable after [podcasting 2.0's spec](https://podcasting2.org/podcast-namespace)

What if clients just "open" the url and custom protocol handlers can take over from there? So https: would go to a browser, nostr: would go to the user's nostr...