Nostr Web Client

The hardest part of developing group chats is managing members—adding and removing them—without relying on a centralized server.

nostr:nevent1qvzqqqqqqypzpwgv8jm36e358cq3qn2unt0hmvzaxejnk9mqrlum9m464qd7v7prqy88wumn8ghj7mn0wvhxcmmv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzquvlyqd6aqss0k7q60mflf2cc2rttp03m98wwhevlgrg5l7th2cxnc4v94

Garbage nsec 4mo ago

It's a hard one. I like the idea of SGX enclaves. Anyone can spin up a bare metal machine with an SGX enclave. The runtime code can be attested via MRENCLAVE, and now there's (somewhat) decentralised verification with the attestation quote signed with an ECDSA key, not hitting Intel's servers.

That SGX enclave could run the member control for the group, programmed to handle commands like add-member and remove-member. The code is pre-defined and public. The SGX enclave would publish membership updates as regular Nostr events.

If an enclave is compromised or the code is changed, the MRENCLAVE hash would no longer match the trusted value. Group members would immediately detect this. The group could automatically failover to a pre-arranged backup or (somehow) collectively agree on a new enclave.

This is all very fuzzy. But something combining decentralised SGX enclaves and multiple nostr relays seems to me worth looking into.

Reply to this note

Please Login to reply.

Discussion

trev 4mo ago

Struggling to see the benefit of the enclave managing the group members instead of just an admin, but maybe I'm just missing a bunch of details.

For the decentralized enclaves, I've been doing this exact thing using TLS established with quote attestation so that you're doing only trusted comms. Once Intel shutdown the CAS servers and discontinued consumer CPUs with SGX it became a huge PITA lol.

Another thing I've worked on was using distributed (or threshhold) signing of the enclave so that a party can, as you said, collectively agree on a new enclave.

trev 4mo ago

> benefit of enclave managing the group members

Actually, I'm dumb, ignore me.