hodlbod

One potential implementation difficulty is that if someone follows/unfollows a single user multiple times, when streaming the events back in out of order they'll have to keep track of when...

As I work more with it, I think Nostr is basically an event-sourcing database with domain objects implicitly layered on top. In this PR I started by trying to define...

To delete an event, you must know its id. For lots of reasons, you might not have that id, but especially if the follow came from a kind 3 ~or...

> Wait, kind 10002 has follows too? Sorry, I get confused between follow lists and relay lists, ignore that > From a UI perspective, you have to know that the...

It occurred to me this morning that another use case this supports is allowing clients to show notifications when you are followed/unfollowed by someone. Currently, since 3's are replaceable, there's...

I'm thinking something along the lines of: `{kind: 10, content: "", tags: [["p", ], ["p", ]]}` > all kind 10 and 11 events that are older than the kind 3...

That list seems pretty unfair tbh, most of those downsides on my proposal are marginal performance differences, general criticisms of nostr itself (relays may have incomplete set of events), or...

It occurs to me a difficulty with this is counting followers, since if these aren't replaceable events, there can be duplicates. A "d" tag would probably fix this.

> Kind 3 events can have an e tag pointing to the previous kind 3 event the new one modifies. This would allow clients to detect forks and create a...

Yeah, I'm with Vitor, I think kind 1s are not exactly central to nostr, in that you can use nostr without using kind 1. Kind 1s do have a privileged...