> NOSTR is the **parallel layer Satoshi described**—the free-speech nervous system sitting on top of Bitcoin’s indestructible money. Nostr doesn't sit on top of Bitcoin.

Thank you!

Test failed: comments should be kind 1111 events, not kind 1 notes. Kind 1 notes should only be used as either root text notes or replies to other kind 1 notes, not as comments to events of any other kind. When the event is addressable, only the address should be referenced (with an "a") tag, not the actual event (so no "e" tag).

> that is the event from which our chain of events starts, No, that would be the root. It mentions, as if it were quoted (by an outdated specification), the grandparent event. I don't know why Coracle needs a reference to the grandparent event (it doesn't: if it did it wouldn't be able to display threads which weren't written using Coracle), but it surely shouldn't appear to have been quoted.

You would need an event signed with the first key that references the backup key, no? If I get access to your private key, I can just publish an older event certifying a public key I control. Anyone who tries to visit your account will be redirected to the oldest verified public key (my own).

If that is true, that is rather disappointing. Nostr communities for the mostly-relay-ignorant should be a thing.

How do you know what happened before what? The timestamp in Nostr events is not certified by default. It's only signed as part of the event, you can post from the past and from the future if you want. Would that require certifying timestamps, thus adding more complexity? Consider this is aimed at the dumbest users, the most likely to paste their nsec where they shouldn't.

It's "nice" to see Coracle is still including random "mention" tags for events that were never fucking mentioned and are upstream in the branch. Not even the whole branch, just a random ass event from the branch which clearly hasn't been mentioned, just to fuck with the event structure a bit.

I am aware, that's why I said "used to". It's still one of the most understood kind of events (possibly, just possibly, beneath kind 0) and doesn't need an "alt" tag. Any client unable to understand kind 1 probably won't understand alts either.

> but also there's nothing inherently wrong with those tags Yes, there is. A space-concatenated list of relays? With encoded spaces? That just reads like a very long, technically valid but clearly incorrect URL. > Who goes around critiquing event structure anyway? I do. I do and more people should. Calling out bugs is a good thing. > That's like walking around with an x-ray and commenting on the ill shape of someone's floating rib. It's not. I don't own an x-ray machine.

Ok, but how would you actually technically achieve what you want?

I think for a classic Twitter-like client it may be problematic because the user would want the change to be effective immediately (especially if they use multiple clients, but even if not so), at least for the general purpose of following and unfollowing an account with the press of a button.

Besides the useless "alt" for kind 1 notes (the most commonly known kind of event, which used to be defined in NIP-01), you also have duplicated "p" tags: [ "p", "9ce71f1506ccf4b99f234af49bd6202be883a80f95a155c6e9a1c36fd7e780c7", "wss://premium.primal.net/" ], [ "p", "9ce71f1506ccf4b99f234af49bd6202be883a80f95a155c6e9a1c36fd7e780c7", "wss://premium.primal.net/" ] What client are you using?

Note that you don't need to send a new event for each user you unfollow. If you are using a Twitter clone (the main, most common and most obvious application, but not the only one), then yes, at each click a new list should be generated. But if a tool is designed specifically to mass unfollow users, it may and should have a button to upload the list at the end of the selection, so only one new updated list has to be sent.

There is something wrong with this tags in your event: [ "p", "7ed7d5c3abf06fa1c00f71f879856769f46ac92354c129b3ed5562506927e200", "wss://nos.lol/%20wss://nostr.land/%20%20avatar%20wss://nostr.wine/%20%20avatar%20wss://purplerelay.com/%20wss://relay.damus.io/%20wss://relay.snort.social/" ], [ "e", "f5e11af65db78f84219e7c11dce5f21e5b96b84688fcbdf8a85a503980cf93c5", "wss://nos.lol/%20wss://nostr.land/%20%20avatar%20wss://nostr.wine/%20%20avatar%20wss://purplerelay.com/%20wss://relay.damus.io/%20wss://relay.snort.social/", "reply", "7ed7d5c3abf06fa1c00f71f879856769f46ac92354c129b3ed5562506927e200" ] Either your client is configured badly or there is some bug.

Fetching all users followed by you would be a mess, just like, currently, fetching the list of people that follow you is a mess (and clients may get it wrong, by listing people that used to follow you but no longer do). Remember that relays have different data and no relay has all data. So if you follow and then unfollow me, even if the specification says the unfollow event must delete the follow event, some relays will still have the follow event. The client would have to fetch all your follow and unfollow event and the list will be complete only once it has received all events. Currently, the client still has to fetches multiple relays and wait for multiple answers, then pick the one with the most recent date, however that's less work than it would be required if there were follow events. I still think that individual follow events (but not really unfollow events) should exist for the purpose of providing a notification when someone follows you.