as fiatjaf would say, no 'group' is truly private, the larger it is, the less private it is.

so im not quite sure what youre wanting but, what does the overloaded term 'private' mean in the context you are looking for?

if you can answer this, then i can suggest things.. but i find this important point, if not understood is a source of much nostr confusion.

Reply to this note

Please Login to reply.

Discussion

1) Private = generally nothing is publicly readable

2) Having your own relay + server should be incentivized but not required

3) It needs to be able to be a private group, not just a private chat, where every content type can have their own criteria for how long they can be accessed and who can publish them.

4) Leaking any key (except for maybe the groups key pair) should not be a significant problem

5) Ideally, if I share the group ID, you can only see anything about the group if that group lets you. (but I'm fine if that's a feature for the run-your-own-server crowd)

...

I can see a way of doing all of this with MLS, but it introduces so much complexity :hot:

id suggest doing some real brainstorming on this. i will too. if you already went directly to "we want what mls does" you have to realize its cutting edge cryptography and im not aware of *any app where it is in use because it is do new.

signal, simplex etc etc, they ALL use the tried and true 'unscaleable' ways, much like nip17. good for small group, not good for large.

so... there are some middle grounds i think, but, all the fancy stuff like forward secrecy, or users joining the chat and being unable to see the history and stuff like this, i think may be far fetched and possibly not even wanted. (many complain they cant see the history, discord doesnt do this, do you consider discord a private chat? many do.

this is why its worth, thinking further.. take the time.

Yes :110percent:

also, in an effort to describe my thought patterns here. nip42 auth, and a relay, .. can control read access to a relay. maintain a list of people that can do this, if they take and republish all the notes.. then what? is it a problem?

if so, then maybe people dont want to use their 'main key' in the group, for plausable deniability, right?

the thing about nostr that is different, is the signatures and the portability. so privacy in a sense, is more scary because.. you signed an artifact that is portable and have to trust your group not to leak it.

this is where atlas shrugs and im not sure what it all means.. do we just stop publishing signatures or some other tricks? maybe. but then trust inside the group falls to the relay or community admin.

tombstones are your friend

they identify the content, without revealing the content, and specify that the content is DED

and further, step outside of the dumb relay mindset, and think about a chanserv bot for this situation. it can keep tombstones of deleted data for a long time, they are not big data compared to what they refer to, and nobody can republish them

#realy already uses tombstones... i haven't written the GC for it yet but they already have timestamps

RIP

yeah, that's why i say the old IRC model is the best, because you can set very fine grained policy on retention and access control and even things like users being able to block sending events to users they don't want to see it specifically, or whitelist where you make a set difference of their whitelist versus their blocklist and the chanserv will only deliver events according to the author's preferences

i have been thinking about these subjects for a long time since i started using IRC in 2003

Between private and public is "protected".

or you could say "defended"

I was just thinking of a dev analog.

Private, protected, public functions.

protected sorta means immutable, except for authorised parties

actually, i think that the smart contract language Move has this notion - values that can only be altered by some specific owner, Move was quite interesting in the way that it stripped back the retardation of rust to narrow it to this notion of ownership and exclusive right of mutation

i'll go with Protected tho, it has a nice ring to it that is quite popular in speech these days

Instead of "private" it's "privacy protected"

private is an absolute and impossible to actually achieve, in practice

Yeah, people can just screenshot stuff or copy-paste the json, or whatnot.

it essentially means that only the permitted users can violate the privacy of their peers, the servers are programmed to restrict access without proof of membership in the group

i'm done with fiat mining for today, wrote a nice paginated iterator thing for them

so now i'm back to realy, which i'm in the process of documenting fully

but after these thoughts, i am making a mental note that when i come to rewriting the documentation of #realy and its #geyser page i'm going to call it a "privacy protected" relay and define that concisely.

shifting the liability away from the provider is essential to enable providing service, any service that does not protect privacy in this way is instantly less marketable.

exactly. the ideal case is providers hold zero liability

this is an "attack" we can make on the freedumb relays also, as we go forward, just sayin'

Tbh "protected" sounds pretty vague, maybe "hidden" instead?