Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 05:39:02 JST silverpill

   Decentralized identifiers (DIDs) can be divided into 3 categories, depending on where the authority resides:

   - Secret key (did:key, did:pkh).
   - Server (did:web).
   - Blockchain (hundreds of them).

   With a #DID derived from a secret key you can truly own your identity. Unfortunately, key rotation is not supported, and if you lose your key, you lose everything. This can be partially mitigated with distributed key generation techniques that make key recovery possible if only M of N shards are available, but they are complicated.

   Servers can rotate keys, but they can also suddenly disappear, and again you lose everything.

   Blockchain-based systems support key rotation and don't have a single point of failure (if done right). Sometimes they are called "servers with superpowers". However, popular ones are not suitable for the job because writing to them is very expensive and their clients need powerful computing devices and a lot of storage.

   Is there a way around that? Yes. Blockchains can be very lightweight and they don't actually need a cryptocurrency, miners or stakers in order to work. There is a simple consensus algorithm known as Proof of authority, and one of the Fediverse competitors, Bluesky, seems to be planning to build such system:

   https://github.com/did-method-plc/did-method-plc

   >We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium.

   They are afraid to say the B-word, but "permissioned consortium" is exactly what it is. Of course, their identity #blockchain doesn't have to be the only one in existence. I think in the future we might see quite a lot of "identity cooperatives" of different shapes and sizes. Perhaps even a universal client, curl for identity, can be developed.

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Tuesday, 19-Mar-2024 05:54:24 JST bumblefudge

     in reply to

     @silverpill idunno if it's quite the equivalent of `curl` but the universal resolver already has drivers for a lot of interesting did methods, including `did:plc` ...
     https://dev.uniresolver.io/

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 05:54:24 JST silverpill

     in reply to

     • bumblefudge

     @by_caballero the curl for identity should be a command line tool that can read and write to blockchains without intermediaries (basically, an ultralight client)

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Tuesday, 19-Mar-2024 06:12:16 JST bumblefudge

     in reply to

     @silverpill also, i would argue there is a fourth category of DIDs, which IPNS *almost is* (and was in 2019 when did:ipld was created to wrap it in one): DHT methods. Check out:
     https://did-dht.com/
     (also indebted to the sidetree family of DID methods, like orb and ion)

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 06:12:16 JST silverpill

     in reply to

     • bumblefudge

     @by_caballero Oh yes, I forgot about DHT, they are indeed a separate category. Haven't seen them used in practice though.

     IPNS has potential, but only if it can work without publisher being online all the time, otherwise it's basically a server (did:onion has the same problem).

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Tuesday, 19-Mar-2024 06:12:17 JST bumblefudge

     in reply to

     @silverpill oh, you wanna WRITE too?
     https://uniregistrar.io/
     (less drivers/testing/maturity)

     cheqd is a cosmos SDK chain, might be one of the interesting ones to look at (i mentioned it on codeberg because it already has pathing and complex DID URLs, but i'm not too familiar with the details)

     in my experience very few blockchain protocols really prioritize light-client use-cases in their core design/budget/spending, unfortunately...

   • Embed this notice
     bumblefudge (by_caballero@mastodon.social)'s status on Tuesday, 19-Mar-2024 06:12:17 JST bumblefudge

     in reply to

     @silverpill i would also note that `curl` is already the `curl` of ipfs and ipNS resolution; since the latter can be thought of as a DID method of sorts (it translates an opaque, self-certifying/content-addressed string into something a lot like a DID Doc), we might not need a new thing at all:
     https://curl.se/docs/ipfs.html
     note that in IPFS' case, the trick is in the protocol handler!

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 08:31:41 JST silverpill

     in reply to

     • Grey Area

     @greyarea Thanks for the pointers. I probably won't work on this myself, my job is to pick a winning technology and integrate it. The winner is going to be the most resource efficient solution that supports key rotation and has redundancy while being user friendly.

     One interesting project that I discovered some time ago just has come to mind: https://github.com/Revertron/Alfis

     It is a lightweight blockchain-based naming system without cryptocurrency. Great idea, but it's PoW-based. There is gap between this and regular servers, and I think it needs to be filled.

   • Embed this notice
     Grey Area (greyarea@mitra.vpclmulqdq.moe)'s status on Tuesday, 19-Mar-2024 08:31:42 JST Grey Area

     in reply to

     @silverpill

     In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.

     As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.

     https://github.com/ongardie/dissertation
     https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 19:31:58 JST silverpill

     in reply to

     • Erlend Sogge Heggen

     @erlend No, did:plc is not good, it is just a centralized and vendor-locked version of did:web. Even if they manage to switch to a distributed architecture, fediverse developers should avoid did:plc because it is owned by a company that develops competing social network.

     Good Enough solutions are did:web and did:key.

     - did:web is equivalent to what we already have in Fediverse: keys are controlled by instances. But FEP-ef61 separates identity and data, so you can have data portability even though identity is still attached to a single server.
     - did:key is equivalent to what Nostr does: keys are controlled by users

   • Embed this notice
     Erlend Sogge Heggen (erlend@writing.exchange)'s status on Tuesday, 19-Mar-2024 19:32:00 JST Erlend Sogge Heggen

     in reply to

     @silverpill while I’m clueless about this stuff at the low level, it seems to me like did-plc is Good Enough for a starting point that works *today*.

     It is transitory by design, so whichever next-stage direction the Bluesky devs take it in can be diverged from if it doesn’t align with the requirements for #NomadicIdentity in the fediverse.

     I’m afraid that if we wait around another year++ for the perfect solution to come along, Good Enough alternatives will be deeply entrenched by that time.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 19:48:29 JST silverpill

     in reply to

     • Erlend Sogge Heggen

     @erlend

     did:web is a standard with multiple implementations

     did:plc is single implementation deployed on a single server

   • Embed this notice
     Erlend Sogge Heggen (erlend@writing.exchange)'s status on Tuesday, 19-Mar-2024 19:48:30 JST Erlend Sogge Heggen

     in reply to

     @silverpill what makes it vendor-locked?

   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Tuesday, 19-Mar-2024 20:02:49 JST Sexy Moon

     in reply to

     • Erlend Sogge Heggen
     @erlend @silverpill prediction: they will never transition away from placeholder.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 20:05:30 JST silverpill

     in reply to

     • Scott M. Stolz

     @scott DIDs are built from permanent identifiers: a public key, a URL, or an address of a record in a distributed database. I don't know if Zot and Nomad have that.

   • Embed this notice
     Scott M. Stolz (scott@authorship.studio)'s status on Tuesday, 19-Mar-2024 20:05:32 JST Scott M. Stolz

     in reply to
     @silverpill One way to implement key rotation would be to implement a hybrid solution, similar to how nomadic identity is handled in the Zot and Nomad protocols.
     
     Your fediverse address is tied to a server, but your identity is not. You can change your server & address, and still keep the same identity.
     
     You could use such a system to handle key changes for an identity. Even though the identity itself is nomadic, an authoritative server can announce a key change for an identity, similar to how an authoritative DNS server can announce changes to a domain name's IP address.
     
     Of course, none of that uses DIDs. But you might be able to take some of the concepts and apply it to DIDs.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 20:11:28 JST silverpill

     in reply to

     • Erlend Sogge Heggen

     @erlend The address of the server (https://plc.directory) is written in the specification:

     https://github.com/did-method-plc/did-method-plc?tab=readme-ov-file#did-creation

     Alternative deployments are not allowed. Even if they remove this requirement, what's the point? did:web is simpler and better

   • Embed this notice
     Erlend Sogge Heggen (erlend@writing.exchange)'s status on Tuesday, 19-Mar-2024 20:11:29 JST Erlend Sogge Heggen

     in reply to

     @silverpill sure, but that doesn’t make it vendor-locked. If others are free to host their own deployments, there’s no lock-in there.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 20:39:36 JST silverpill

     in reply to

     • Grey Area

     @greyarea Do you know any wallet-like tools (CLI or GUI) that implement FROST?

   • Embed this notice
     Grey Area (greyarea@mitra.vpclmulqdq.moe)'s status on Tuesday, 19-Mar-2024 20:39:37 JST Grey Area

     in reply to

     @silverpill

     Nice thing about FROST is that it already works with did:key with Ed25519, since signatures and public keys are compatible. secp256k1/secp256r1 are not, since FROST is Schnorr signature based rather than ECDSA.

     As far as the gap goes, IMO that's where crash fault tolerant consensus algorithms (Paxos, Raft, etc) fit in. Non-POW Byzantine fault tolerance tends to be tied to Shitcoinery because the systems only allow up to < 1/3rd of the participants being malicious (2f + 1 need to be non-Byzantine), and the "best" way that's been found is economic incentives.

     The original PBFT paper/research from 1999 used a NFS file-server implementation as the practical example, but "people are assholes, and someone will spin up a mountain of nodes" isn't something that was in-scope when they did the research.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 21:24:29 JST silverpill

     in reply to

     • Scott M. Stolz

     @scott Identifiers based on public keys are not permanent if keys can be changed. It sounds like identity here lives in associations between certain keys and certain servers.

   • Embed this notice
     Scott M. Stolz (scott@authorship.studio)'s status on Tuesday, 19-Mar-2024 21:24:30 JST Scott M. Stolz

     in reply to
     @silverpill
     DIDs are built from permanent identifiers: a public key, a URL, or an address of a record in a distributed database. I don't know if Zot and Nomad have that.
     Zot and Nomad have permanent identifiers that are based on public keys. In the database, the user's identity is stored as a hash. Currently, the key pair and hash never change for an identity, but the URL and address can change. The primary URL and address tell you what server is authoritative and where to send messages.
     
     And since Zot and Nomad allow you to have clones, as long as your message is signed with the correct keys, it is considered you, regardless of which clone (domain name) that you posted from.
     
     If you wanted to be able to rotate or change keys, an authoritative server would have to tell you that the old key and new key are equivalent and the same identity. And then your software would need to be able to recognize that.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 22:01:44 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron @erlend Can ownership depend on approval by a group of authorities but otherwise be free?

     (At least in theory - in a hypothetical Alfis fork)

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Tuesday, 19-Mar-2024 22:01:45 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @erlend @silverpill Yep, it is very unlikely to change. Ownership of a domain must have a price.

   • Embed this notice
     Erlend Sogge Heggen (erlend@writing.exchange)'s status on Tuesday, 19-Mar-2024 22:01:46 JST Erlend Sogge Heggen

     in reply to

     • ⚛️Revertron :straight:

     @silverpill that’s an interesting one.

     @Revertron is the PoW approach in Alfis unlikely to change?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 22:33:14 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron @erlend This is a trust model of a fediverse server. People may dislike authority when there is only one name database, but there could be hundreds of them.

     Blockchains are usually engineered with an assumption of powerful global adversary. That makes sense for a financial system, but not so much for identity. The system that I want is closer to a regular server, it only needs enough redundancy to survive a hardware failure and an admin who forgot to renew the domain name.

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Tuesday, 19-Mar-2024 22:33:15 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill You may do this, but the people don't want any authority to "approve" their domains.

     @erlend

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 23:00:20 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron Good question, and I don't have a definite answer. Perhaps databases can be identified by a public key of an authority (or something akin to a multisig address)? A fully qualified name may look like this:

     myname.z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK.namesystem

     That makes it poor DNS alternative (names are not human readable), but it's good enough for decentralized identity

     @erlend

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Tuesday, 19-Mar-2024 23:00:22 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill > but there could be hundreds of them

     And how will they interoperate?
     For example, I have my own DB, you have yours. I direct my PC to resolve names from my DB, you from yours. But domains are different, even intersecting.

     @erlend

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 19-Mar-2024 23:09:47 JST Hyolobrika

     in reply to

     • Sexy Moon
     • Erlend Sogge Heggen
     I suspect that as well.
     Sexy Moon likes this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 23:10:06 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron I should probably provide more context. The goal is to build a user-friendly decentralized identity system for Fediverse. It will co-exist with DNS-based handles like @user@social.example, so readability is not a priority.

     The idea is described in more details in this proposal: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

     Key-based identity will also be allowed, so people who want more control could choose that. The 'smallchain' option that I'm thinking about is supposed to be a middleground between key-based identity and centralized identity providers.

     @erlend

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Mar-2024 23:22:32 JST silverpill

     in reply to

     • Hyolobrika
     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Hyolobrika @erlend @Revertron The advantage is having a choice between owning your identity key and trusting an authority (with varying degrees of trust: single authority, friendly majority, etc).

     This is possible because identifiers will be based on DIDs.

   • Embed this notice
     Hyolobrika (hyolobrika@social.fbxl.net)'s status on Tuesday, 19-Mar-2024 23:22:33 JST Hyolobrika

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen
     If you have to trust your identity to an authority, then what's the advantage of your vision for fedi over nostr?
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 00:07:46 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron See adjacent comment:

     https://mitra.social/objects/018e570a-c86d-b3d8-caf2-88dfb8eaf5aa

     I think it is better to avoid logically centralized systems. From the perspective of a user, cryptocurrencies are a total disaster, it's like 10000 competing standards. Only a tiniest fraction of them have network effects strong enough to matter, and you're constantly pressured to pick a single database, though of course all of them have different tradeoffs so it is not really possible.

     Instead there should be one standard and 10000 competing providers.

     @erlend

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Wednesday, 20-Mar-2024 00:07:47 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill Don't try to invent the wheel :)
     Database must be single and replicated. And generally you should choose between PoW/PoS and PoA.

     Why do you need such a system in the first place? I didn't get it.

     @erlend

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 00:22:10 JST silverpill

     in reply to

     • Moto :rainbowinfinity:
     • Erlend Sogge Heggen

     @cmdrmoto @erlend No, DID 1.0 specification doesn't require central directories. Many DID methods depend on some kind of registry, but I think in most cases it is based on distributed ledger technology aka blockchain, so when developers make claims about decentralization, they are not completely untrue.

     did:plc is not like that, it is literally a single server, and I have no idea why Bluesky team uses the term "DID". Fake-it-until-you-make-it, I guess.

   • Embed this notice
     Moto :rainbowinfinity: (cmdrmoto@hachyderm.io)'s status on Wednesday, 20-Mar-2024 00:22:11 JST Moto :rainbowinfinity:

     in reply to

     • Erlend Sogge Heggen

     @silverpill @erlend Indeed:
     “A central directory server collects and validates operations, and maintains a transparent log of operations for each DID.”

     Ironic for a Decentralized ID to be anchored around “a central directory server,” for sure. Is did:plc actually a “Must” implement for DID 1.0 compatibility?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 00:41:26 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron Coins need to move between providers, so bridges between providers and some shared database is probably unavoidable. I think with identities each provider can have different database.

     @erlend

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Wednesday, 20-Mar-2024 00:41:27 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill
     But those providers must have the same synced DB.

     @erlend

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 02:51:11 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Erlend Sogge Heggen

     @Revertron Yes, but this still requires a single database, right? Only the second tier (namespaces) is logically decentralized.
     What if there is a single peer to peer network, but multiple databases, each database is completely independent and can not be removed from the network. Like torrents, but with mutability. Is it possible?

     In such network clients will only download data they actually need, and each database will have its own rules (small invite-only namespaces, big commercial ones, and everything in between)

     @erlend

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Wednesday, 20-Mar-2024 02:51:14 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill @erlend
     The easiest way is something like this:

     1. We have one small blockchain without coins.
     2. Every server is proving their authority over their domain, and create a block in blockchain.
     3. Every other node/server is checking for some key published on that server, for example server1.example/root.key AND accept that block in their copy of blockchain.
     4. After that this server can create IDs in its 'namespace', signing blocks with new identities by its key.
     5. Maybe every identity can have their own keypair to move from one 'namespace' to another. Even if that server1 dies.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 04:12:47 JST silverpill

     in reply to

     • ⚛️Revertron :straight:

     @Revertron Well, maybe we shouldn't call it blockchain then, but it doesn't have to be a single entity. Torrents and IPFS objects can't be removed. In fact IPNS is probably the closest thing to what I want, but it is too slow and buggy and the client is not lightweight.

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Wednesday, 20-Mar-2024 04:12:49 JST ⚛️Revertron :straight:

     in reply to

     • Erlend Sogge Heggen

     @silverpill
     > independent and can not be removed

     This is why the blockchain must be a single entity. Every node should have ALL info if you want it to be not removable :)

     @erlend

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 04:18:59 JST silverpill

     in reply to

     • ⚛️Revertron :straight:

     @Revertron Also IPNS name is controlled by a single key, but in a proper system control should be distributed

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 05:04:08 JST silverpill

     in reply to

     • ⚛️Revertron :straight:

     @Revertron A single person, or a group, or a company. Let's assume for a moment that IPNS performance has improved and it supports FROST or something like that.

     The IPNS name is a namespace root. It is a pointer to some verifiable data structure, probably an append-only log, where all identity operations are recorded: add key, update key, revoke key. If the root key of namespace is distributed, no one can single-handedly add or remove an identity. Operations are performed only by a consensus or a majority vote.

     Such system would have all desired properties: redundancy on all levels, organizational diversity (no logical centralization), no payments required, key rotation is possible, user friendly.

   • Embed this notice
     ⚛️Revertron :straight: (revertron@zhub.link)'s status on Wednesday, 20-Mar-2024 05:04:09 JST ⚛️Revertron :straight:

     in reply to

     @silverpill Distributed to which entities? Who will own those names?

   • Embed this notice
     Grey Area (greyarea@mitra.vpclmulqdq.moe)'s status on Wednesday, 20-Mar-2024 07:31:40 JST Grey Area

     in reply to

     • ⚛️Revertron :straight:

     @silverpill @Revertron

     So something like certificate transparency logs, but for identities?

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Wednesday, 20-Mar-2024 07:31:40 JST silverpill

     in reply to

     • ⚛️Revertron :straight:
     • Grey Area

     @greyarea @Revertron I didn't know about transparency logs. Yes, sounds exactly like that

     https://certificate.transparency.dev/howctworks/

     >A certificate ties together a domain and a public key.

     And in our identity system certificate would tie a name in namespace and a public key.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 24-Mar-2024 05:38:18 JST silverpill

     in reply to

     • Moto :rainbowinfinity:
     • bryan newbold
     • Erlend Sogge Heggen

     @bnewbold @erlend @cmdrmoto If this system will have multiple identity roots (logically decentralized, not a single database), and will not depend on DNS, it might be actually useful.

   • Embed this notice
     bryan newbold (bnewbold@social.coop)'s status on Sunday, 24-Mar-2024 05:38:19 JST bryan newbold

     in reply to

     • Moto :rainbowinfinity:
     • Erlend Sogge Heggen

     @silverpill @erlend @cmdrmoto "permissioned consortium" could in theory be a blockchain of some kind, but are more interested in a transparency log like Certificate Transparency, particularly the recent more efficient "tile" implementation work by Let's Encrypt

   • Embed this notice
     bryan newbold (bnewbold@social.coop)'s status on Sunday, 24-Mar-2024 05:38:20 JST bryan newbold

     in reply to

     • Moto :rainbowinfinity:
     • Erlend Sogge Heggen

     @silverpill @erlend @cmdrmoto folks are totally welcome to do mirrors and alternative deployments or forks or whatever they want. there is an audit log to facilitate this

   • Embed this notice
     bryan newbold (bnewbold@social.coop)'s status on Sunday, 24-Mar-2024 05:38:21 JST bryan newbold

     in reply to

     • Moto :rainbowinfinity:
     • Erlend Sogge Heggen

     @silverpill @erlend @cmdrmoto PLC today works with centralized servers for convenience, but it doesn't have to stay that way. the core of the method is self-certifying identities, and that info could be distributed any number of ways.

     I gave a talk recently about PLC and ways to de-centralize it more while staying backwards compatible (video, transcript, slides):
     https://fission.codes/blog/fission-tech-talks-bluesky-and-plc/