Depends what you mean:
Conditional WRITE 👉 Yes :110percent:, that's the value prop. You specify your conditions per content type.
Conditional READ 👉 No, looking into multi-content private groups for that rn (MLS, IRC, ...).
Discussion
Will conditional read ever be possible?
Private relays that have whitelisted only readers that are designed not to propagate beyond those readers?
It's possible with the closed community network platform I'm building!
It's quite the trade-off circus in my mind currently for that.
Because I don't want to force newcomers to set up their own hosting just to try something "simple" (in their mind) as private groups / files.
So then the Nostr + MLS route is quite appealing.
But I can't put all content types in one MLS group because they all have different desired retention times and privacy concerns.
Running your own relay shouldn't be complicated. Nostr is a very simple protocol (which is a good thing), and you can just embed the relay into the application (as I'm doing with Eve).
The relay then fetches encrypted events encrypted with the CCN key (and soon using MLS, for the added security), and stores them into a database on the user's device, users don't have to know anything about that, they just know that when they open Eve, everything they see is only the content in their closed community network!
So you're planning to use the MLS keys for giving access to a database?
Could I then have something as simple as this? 👇
Chat → MLS group chat
All other content → Encrypted in private database, accessed with MLS keys
And how do I link the database to the group? In the nostr_group_data extension? Or in another event that encompasses both MLS group and database?
Kind of, the database is in the user's device, they always have access to it. Users of Eve use the integrated relay for every read and write operation, and it handles the encryption and decryption of data.
When the user creates a new note, this is encrypted and the encrypted note is broadcasted to a bunch of random public relays (when the user is online).
When the relay sees a new note encrypted with the same key, it tries to decrypt it and if it can it stores it into the database.
The transition to MLS doesn't require anything in particular; a nostr note is just a "text" message.
In fact in the future, I'm even thinking about implementing additional protocols for posting transmitting notes that don't require a receiving relay).
The reason why I'm doing it this way is because I don't want Eve to be limited by any specific encryption methodology. In the future if something better than MLS (such as a PQC algorithm similar to MLS) comes as along, I can just change the part of the code that handles encryption and decryption and suddenly all new content is encrypted with a stronger algorithm.
And the user runs their own relay both because of simplicity in implementing all of this, as well as security, and so they can access their networks' data (nostr notes) even when they're offline (and in the future with the bluetooth based negentropy that npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh is building, this can improve even more)
And how do you define/address the group?
The system that I have at the moment (which naturally won't be the final version) requires users to share a key which they enter in Eve on the first run. Users entering the same key will be part of the same community.
In the near future (hopefully by tuesday/wednesday), users will be invited to the CCN by sending each other an invitation file, which will include a key that the user's relay will use to decrypt a message containing the main CCN key.
The reason for the in-between key is because I'm building a reputation system into Eve, and I need a way to link the invitee to the inviter (which is a whole other discussion haha)
As soon as the application gets more stable, and I fully build MLS support, this will change a little bit to include the TreeKEM related information
Oh, and I missed the step that every invitation can only be used once because it includes step where the newcomer has to sign their pubkey into a message to the CCN's private key, and the relay will be setup to ignore repeat messages with the same invite code.
I see!
Very interesting sir! Brave work you do.
Curious about that last part mostly. I like the MLS invite model.
Just need to know where and how to best specify the content types that go beyond Chat.
With the way that I'm implementing it you don't need to specify any extra content types, it's all one content type for a "chat message" that's basically a JSON encoded nostr event, the relay handles everything else
Can I make queries for only content type XX work in a realistic way like that?
Once the notes are in your relay you write apps just like for the public nostr, just only querying that relay. A kind 1 client, will just query:
{ kinds: [1] }
and the relay will handle the rest.
For example take a look at the code for the topic view in the forum
https://git.arx-ccn.com/Arx/Eve/src/branch/master/src/routes/Arbor/TopicView.ts
There's nothing in the code that deals with encryption, there's a complete separation of concerns.
```
this.subscription = ndk
.subscribe({
kinds: [893 as NDKKind],
'#E': [this.topicId],
});
```
The client doesn't know how the encryption works, it all happens automagically; the relay manages everything.
Any query that works on nostr, for open, non encrypted data, will work on Eve for your Closed Community Networks' specific content, no matter how complex the query, if it can be done on public nostr relays, it can be done on your private Eve Relay (and there will also be more complex queries supported in the future, such as negative queries).
Ok, I didn't express myself clear enough, sorry.
I mean, let's I open a 3D models app and I want to give it access to the private 3D models of my groups.
How can I do that, without it having to download and decrypt the whole group state?
Do I then have to send (somehow) the relevant events from the device/app where I do have the full group state (relay)?
It being a relay, might already help with that though. So maybe there's something there.
Right now this is not built, but the relay will also act as a blossom relay, which will allow you to upload files to your community (and the files are also encrypted and shared in the same way).
I don't think that the space required to download and decrypt the group state is a concern right now, nor is it in scope for Eve to be honest.
The expected use case assumes you communicate with your community from a single device, sharing data from other devices to the one running Eve is a solved problem (syncthing works well for example).
Looks like there is a lot of overlap with communikeys but Alex is specifically focused on private groups. Your approach is very interesting!
s/Alex/Arx 😅
Thanks for these replies man!
Will look into it more when my brain doesn't say "It's Friday dude, wut you doing?".
Definitely align a lot with your goal.
Have you seen this specification? "messaging using MLS"
I have, yes, this is what I'm basing my MLS implementation on
Possible with NIP-42 auth (some groups already doing this rn).