U

Yes, unfortunately only public lists.

Reply to this note

Please Login to reply.

Discussion

Another benefit of an "outbox model" is that it's asking only their relays about their notes (without auth) so still somewhat private.

Not entirely sure yet how to have a private relay fetch these without access to decrypt the list. Will have to think about this one, perhaps lists could be shared with other pubkeys.

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.

Right, however in my case, I noticed the relay was either a paid relay that we happen to share (single point of failure) or a wot relay that uses someone elses pubkey (not including my contacts, even if I'm in theirs) and will probably only store notes temporarily.

Yes that is part of it. With many different clients; short notes, git collaboration, long notes, video, audio, markets (desktop or mobile) and etc. (desktop or mobile), it could get quite complex for each separately to do all the heavy lifting of communicating with thousands of relays, etc. etc.

The "unfortunately" refers to Amethyst.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z 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 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z 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/

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 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 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

Thanks, good catch, it actually seems a bug in the decoding.

Haha... interesting find. Probably a small bug with some code that will omit empty lists and the encrypted list "appears" empty.