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.
Can I not use Amber? Not sure how to log in 
That's right. NIP-46 signers don't work with this app.
I explained why here:
nostr:note1v2fdytj44trsnvt7yqal83r7c0mxfl4y5qqdrvp9uqaj9tpyf3ysd7n0gf
Good idea! I havenβt even tried this myself but Iβve been told it works well.
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?
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.
But this is a false dichotomy.
You don't need to either fragment it in small events, uniformative until combined, or put all the information in one massive event.
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!
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.
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.
Itβs not really inconsistent, because posts and reactions are one-off events, as opposed to lists that need curation. The protocol treats these differently.
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.
I think nostr:npub1mmwcn367jw2g8c48y70975grw6jrhet2pshukxe872yzh3wmt7tq4qaum2 is suggesting not having a list at all.
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!
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.
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?
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.
This is not to say a better solution, in the form of some middle ground, cannot be possible, by the way.
There could be a "main" follow list which only contains references to smaller lists.
Each individual event would be reasonably small, but once you fetch the latest main follow list you would know all referenced events are up to date.
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.
We couldn't have an event with the list of replies if we wanted.
Also, replies are meaningful even before you collect all of them.
Furthermore, kind 1 text notes (which include replies) and kind 1111 comments cannot be edited or deleted (delete requests can be ignored and are ineffective if the note has spread to other relays). When you get a text note, you know it's valid. But if you get a "follow" or "unfollow" event, you don't know yet, because the user might have followed or unfollowed that account at a later time, invalidating that event, so you have to wait until you have all data for any of it to be valid.
There are cases where the whole follow list of multiple users can be needed, preferrably quickly.
The offshoot threads on this post are super interesting
fiatjaf said 200 - maybe 500max
then user do many npub or lists
Yeah, but clients have inconsistent support for lists. So Iβm still looking for other criteria to mass unfollow more users.
need stick with best list client only - lists becomes invisible otherwie or use multiple npubs each 500 followers max - no other way
diff Q - do u know if phoenixd (not andriod one) use BIP39 with '0/84/0/0 derivation path ? bc1xxxx seqwit format address
Are you talking about the on-chain deposit address? I donβt think it matters, since they just perform a swap to Lightning from the amount received.
yes - force-channel close due to offline/inactive
phoenixd NOT phoenix
there r diff minor
I donβt really know any more than what I can see on their FAQs. Maybe someone else in the nostr:npub1hxfkcs9gvtm49702rmwn2aeuvhkd2w6f0svm4sl84g8glhzx5u9srk5p6t group can help.
channel closed send amount mainnet - got confirmed
asked them what dormant policy in these things - waiting reply - they r doing channel management for all such LN wallet nodes
Did you try restoring the wallet from your seed phrase in a fresh install of Phoenix?
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.
Agreed, thatβs one of the differences between nostr:npub1pvz2c9z4pau26xdwfya24d0qhn6ne8zp9vwjuyxw629wkj9vh5lsrrsd4h and ordinary clients. You can make selections based on how long your follows have been inactive before purging them all at once. I even built a feature called The Nuclear Option where it blasts them in one shot instead of in batches.
Iβd love to see some more clients build in a way to do this, but it doesnβt seem like a priority.
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.
Correct. But a client that helps you sort your follows by last active date and bulk remove inactive and low-quality follows would be welcome. I donβt even know how I got to 2600, let alone 3600 when I decided to start purging.
decentralize - everyone accept fact many things need self manged different from central db based system
190kb? That is a lot of bandwith to you?
Itβs inefficient, and it all adds up over time when a lot of users are using the same relays simultaneously. You might not be aware of this, but thereβs a hard limit of 64 kb for NIP-44 encrypted payloads, so I canβt even use a signer like Amber or Nsec.app with my profile because my kind 3 events get rejected due to the data cap. My list is almost twice the size of the acceptable length even after reducing it by 1000 follows.
AFAIK, NIP 44 (DM kind4) encryption has nothing to do with kind3 events that has relay limit of 64KB.. If you want to follow more people, host your .json file externally and the point to it in a kind3 event instead of listing all the npubs in a single event, then you can use a signer like Nsec.
NIP-46 remote signers depend on NIP-44 to provide the encryption scheme. I ran into this issue trying to build an app that supported Nsec.app and it didnβt work with my follow list.
Iβm sure nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p or nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z can answer this better than I can.
