Nostr Web Client

It’s funny, but that’s not an accurate description of what happens when you sign an event. Clients can display events differently, but the relays can’t sign them for you.

Mossy Flanagan 2mo ago

What I mean is that typically users send out little bits of data (which are each individually signed) and then the clients aggregate them into different views (for example, the list of people I follow, or the list of people following me or the list of replies to a post). In most cases, the user just sends out the granular action (zap, heart, reply) and it's up to the clients to query the relay and build up the aggregate list. But with the list of follows, it works different, the user keeps republishing the FULL list and the relay treats it as replaceable, it just seems inconsistent with how nostr typically works.

Replying to

The Daniel 🖖

I’m not a protocol developer, so this is probably a better question for someone like nostr:nprofile1qyv8wumn8ghj76twvfhhstnjv4kxz7tn9ekxzmny9uq35amnwvaz7tms09exzmtfvshxv6tpw34xze3wvdhk6tcqyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6luf5tq or nostr:nprofile1qqsvrlrhw86l5sv06wkyjgs6rrcekskvk7nx8k50qn9m7mqgeqxjpvg8u2e5q, but you can read the docs to see how events are handled.

Here’s how I understand it: Your client has to sign a JSON message using your privkey and post it to all of the connected write relays. There’s no way to guarantee which relay has the most recent version of the event, it if even has it at all, so the protocol assumes the one with the newest timestamp is the only one that matters. Sending little bits of data and hoping they will somehow be reassembled correctly on the other side doesn’t play nice with decentralization, unless you’re talking about mining and blockchains, and we’re not.

https://nips.nostr.com/1#kinds

Mossy Flanagan 2mo ago

I think "Sending little bits of data and hoping they will somehow be reassembled correctly on the other side" is actually EXACTLY how Nostr works and that's a good thing!

Replying to

RooSoft

Only sending updates would require the server to be able to sign the list on your behalf.

The whole point of nostr is to transfer control from server to the user.

Mossy Flanagan 2mo ago

Yeah I was thinking something like https://github.com/vitorpamplona/nips/blob/relationship-status/81.md I'm definitely new and still learning the protocol in's and outs!

Replying to

fiatjaf

It just happened without it being seriously planned for, and now we can't change it (despite many attempts from different people) because changing would break too many things.

It's not that bad, though. Well, actually the contact list event shouldn't have to be necessarily mapped to a list of people being followed, they could be independent things. Maybe once more people realize this we will be able to improve the situation.

Mossy Flanagan 2mo ago

I get that, seems like the whole system is moving fast and evolving organically which to me is promising. I guess there is something like https://github.com/vitorpamplona/nips/blob/relationship-status/81.md which seems like it could supersede a simple flat follow list.

How do these things kind of move into widespread use? Is it a matter of enough popular clients adopting the new protocol?

Replying to Valentino Giudice

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.

Mossy Flanagan 2mo ago

I think just publishing the individual follow / un-follow (delete follow) is consistent with how most things work in Nostr. If I want to see all the replies to a post, I have to query relays to assemble that list, same to see followers (as you mentioned) or reactions to a post. It is a mess in some sense but I think it's a good model.

Replying to

The Daniel 🖖

This is what my Nostr contact list with over 2600 pubkeys looks like, and an example of why you should consider reducing your follow count. This 190kb file has to be updated and saved to my relays every time I follow or unfollow someone.

It’s why I built nostr:npub1pvz2c9z4pau26xdwfya24d0qhn6ne8zp9vwjuyxw629wkj9vh5lsrrsd4h and why I’m building more tools to help reduce my (and your) bandwidth footprint.

https://v.nostr.build/8SaPSxZ2yMXvFouH.mp4

Mossy Flanagan 2mo ago

This approach seems a little odd, why not post discrete events to follow and unfollow instead of editing and republishing a list? Just curious why we settled on that approach at the protocol level?

Replying to

Bianka

I would like to sell an online course but I am still new to this. Any ideas?

Mossy Flanagan 2mo ago

I don’t know yet but let’s figure this out! Maybe as a first experiment do a live stream free and get some zaps? I have a close friend who is going to start doing live audio streams soon, getting him setup with keys next week