Oddbean new post about login | logout TIL that Gossip supports private lists and Amethyst supports viewing public lists (not private nor their creation).
U Yes, unfortunately only public lists.
The "unfortunately" refers to Amethyst. @Vitor Pamplona are private lists planned?
Hum.. strange, we have been decrypting private lists from listr.lol for years now.. I will check if there is a new bug in it.
Amethyst used to see private lists created by gossip. I just recently alerted @Vitor Pamplona that this is no longer working. But it did definitely work a few weeks ago. Unfortunately, I can't say what version it stopped working with.
I actually also remember using an encrypted list on Amethyst a long time ago, but now all my private lists are gone.
That may be because some kinds got deprecated. You can recover bookmarks with this tool. Partially, in Japanese, though, it's really useful. https://nostr-bookmark-recovery-tool.vercel.app/ https://cdn.satellite.earth/07fae99a3acd2a2d08272b249c7fc2f496cd080c231bb097263e345179c0af28.png
Thanks, but Gossip produces corrects NIP-51 lists, so the problem should be different.
oh I see. the problem may be the refferenced kind for bookmarks and implemented features for that differ per client? (Amethyst looks like it still uses kind:30001 as a bookmark with supporting public and private lists, while Gossip fetches only private kind:10003 bookmarks)
I'm looking at 30000 "follow list". Amethyst correctly loads plain lists, but it seems to discard the encrypted ones. /cc nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcewvzaw
And I have the same problem with Voyage, nostr:nprofile1qqswgvmv65ja7706f5a0xe8ajcqdfvgdeeppt2jvx0kh06sggg6ykyqppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3uamnwvaz7tmjv4kxz7fwdehhxarj9emkjun9v3hx2apwdfcz75extm3
I was able to create a semi-kludgy work-around.
1. I created a new, non-private list in gossip.
2. i put one non-private npub in the list.
3. i put a bunch of other npubs into the list and toggled them each to private individually.
When i published this list from gossip, it was quickly available in Amethyst and the feed in amethyst does include all the private (encrypted) npubs from the original gossip list. I pulled down the kind 30000 event from my relay and confirmed that all the private npubs are in fact only existing in the content tag in an encrypted blob. The only clear-text ('p') npub is the one non-private contact i added in step 2.
This works but is a PITA.
cc @Vitor Pamplona I don't grasp your concerns, why would a relay ever decrypt anything? Can you elaborate?
For a relay that has your and your networks events with relay-to-relay network topology. I'm working on a tool for strfry that will use a configured pubkey to grab the `kind 3` (NIP-02) contact/follow list and then sync (with negentropy) and stream events for those contacts from their relays defined in `kind 10002` (NIP-65). I haven't added support for other lists other than `kind 3` yet, however it could easily. However, if the list is encrypted, then it wouldn't be able to do that.
Interesting. What's the ultimate goal of this tool?
A few things, however, it solves a problem I have now in Amethyst, which is that many notes are only "seen" by one or two relays (and without connecting to many more relays listed via NIP-65 for contacts). Once complete, Amethyst connects to that private relay (and a few others) and it will stream and sync from many hundreds to thousands of relays. Much more than just a few as it is currently.
> a problem I have now in Amethyst, which is that many notes are only "seen" by one or two relays This should not be a problem, it is how the Outbox model works. Any other additional relay comes from a broadcast from users that interact with the event and this organically increase the decentralization and reachability of user's content. It seems that you want to create an hybrid client/really, that actually could be useful in edge cases to support "thin clients", especially on mobile.
Interesting. What's the ultimate goal of this tool?
A few things, however, it solves a problem I have now in Amethyst, which is that many notes are only "seen" by one or two relays (and without connecting to many more relays listed via NIP-65 for contacts). Once complete, Amethyst connects to that private relay (and a few others) and it will stream and sync from many hundreds to thousands of relays. Much more than just a few as it is currently.
> a problem I have now in Amethyst, which is that many notes are only "seen" by one or two relays This should not be a problem, it is how the Outbox model works. Any other additional relay comes from a broadcast from users that interact with the event and this organically increase the decentralization and reachability of user's content. It seems that you want to create an hybrid client/really, that actually could be useful in edge cases to support "thin clients", especially on mobile.