I just mean if it's on your board then we can consider it to be yours. Works for social use cases and most other use cases. So a Twitter clone, as long as it's pulling from each person's board then I'm not sure why bother signing the individual notes? If someone is saying "yo guys that note is injected, don't believe it" then it'd be pretty easy to diagnose, because it wouldn't exist on that person's board when you went to cross-check. Maybe in some situation where there's a high injection risk and the impact of being misled by an injected note is quite high then sure, sign all the notes. Hard to think of such a case though.

There's still the question of what the keys would even be signing. I don't see much point in signing individual events in the Pubky world. Of course you could do that, but it'd be like wearing a rain coat under an umbrella. If the umbrella is big enough then the rain coat is just extra weight and stuffiness. I guess there might be some niche ultra-high-assurance use cases but I can't think of one.

Everything you can do on Nostr you can do the same thing on Pubky (if you want to). You could essentially port the entirely of Nostr to Pubky, thus taking advantage of PKDNS, if not for the incompatible curves. The nature of PKDNS means everything on Nostr is a subset of Pubky and not the other way around. PKDNS is like a third dimension, where as for Nostr signed indexes, lists, drives, folders and boards all still exist in the same two dimensional space as everything else.

To add to that, for atproto what's signed is the content Identifier (commit) of the new merkle search tree root, and not individual posts. So you sign off on changes of state to your entire history (which could represent the additional of a single post, but not limited to that). Summary: Nostr - Sign the note itself Pubky - Sign DNS beforehand (and the note itself too if you want, but that might be seen as unnecessary) Atproto - Sign the new state of your personal history Farcaster - Sign the note itself (except unlike Nostr the "signers" are delegated) Feels like something would make a good diagram for.

One point of confusion between Nostr and Pubky is that Nostr signs individual events (the post-it notes) while Pubky just signs the pkDNS (the board where the post-it notes are stuck on). On Pubky you could build a client that signs the post-it notes and not just the board. It's just that if you can sign the board then there's less of a need to sign the individual post-it notes, hence the demo client shies away from that.

Nostr certainly seems to be entering a First rule of Fight Club phase.

> companies will not want this information broadcast either, if it links to the company. the users directory events, though, are perfectly fine to be pushed and pulled from company relays if they decide to All of that is perfectly achievable on PKDNS/PKARR/PUBKY though.

If a user's goal is to hide their location then Nostr is not a great choice of protocol. Every relay connection requires the relay to know the user's IP, and that's mandated by the protocol itself, regardless of what the relay does or does not do with this info. And the user needs multiple relays, often random, often out of their control. All relays use DNS relying on certificate authorities and public registrars, registries. Then add in all the media servers (for a single not you need the relay and the media server, and maybe the mirrors too). Then add in the CDN serving the media itself. It's basically standing on a hill and shouting in every direction. And VPNs don't help much. Most VPN use is trivial to detect now (especially on phones), and VPNs cut both ways, a user could be out of the UK and get a UK VPN and now the relay or media server has to treat them like they're in the UK, with appropriate guardrails. So the obligation on Nostr relays, media servers, everything, is very heavy, regardless of VPNs Basically if location privacy is a major concern then a user would not choose Nostr, they'd choose something else.

Thanks! I guess you’re in my timezone, Im in Saigon.

Nice. It has so much potential, but take your time, I can see how NIP60 presents a lot of security and awareness challenges that will be tricky to get right.

If exiting out and then going back to the invite message and then back in again, it will let the new person in, but it will show as a group with only the new person. And then on the device of the person that created the group it will show the group with both people. Same group ID. And messages don’t sync.

Are there docs yet for people to set up their own paid keychat relays for testing?

Great. Another one is when I invite someone to a nip29 closed group, they get the invitation then they tap on it then it says request to join group, they enter the reason, and then it says duplicate already a member and no way to enter.

Ah thanks that's the info I was looking for.

Thanks. Im also having an issue with nip29 groups, testing with three phones, when I send a message on one phone it doesn’t show on the other two unless I back arrow out of the group then jump back in, and then it’s there

Got it! What if one group contains the same members as another group plus one or two more?

Ah, thanks!

seems when you create a new nip17 group and add someone who exists in an old nip17 group with you it just renames the old group instead of creating a new one.

Ah okay see where you're coming from

>if the nostr profile event contains all the outbound references to other protocols, teh other protocols can just refer to it and cover all bases. You cannot just refer to a Nostr profile event. It can exist at the same time in x different forms and x different places. It's like referring to the health status of Schrödinger's cat. The whole reason PKDNS exists is to solve the "refer to it" problem.