The "unfortunately" refers to Amethyst.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z are private lists planned?

Reply to this note

Please Login to reply.

Discussion

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.