synchronized PLC directory
hexmani.ac
1# flenser
2
3dark experimental identity record
4
5[](https://hex.pm/packages/flenser)
6[](https://hexdocs.pm/flenser/)
7
8## how to run (won't do anything for now)
9
10```sh
11gleam run
12```
13
14## what?
15
16**flenser** is an experimental (unserious) piece of software for storing, managing and synchronizing [DIDs](https://en.wikipedia.org/wiki/Decentralized_identifier) using the [did:plc method](https://github.com/did-method-plc/did-method-plc) across a peer-to-peer network.
17
18## why?
19
20the current implementation of the PLC is not meaningfully decentralized, and almost all users on the [AT Protocol](https://atproto.com) network rely on this DID method for their identity. the majority of applications on ATproto currently use [plc.directory](https://web.plc.directory), a service operated by [Bluesky Social PBC](https://bsky.social) entirely in the United States, as a source of truth for PLC documents.
21
22due to its status as the most commonly utilized source for PLC identities, it has become a single source of truth for an identity's status, which allows for the operators to arbitrarily change or delete documents without any recourse from other directory operators. while [a list of invalidated operations](https://github.com/did-method-plc/did-method-plc/blob/main/invalidated-op-log.txt) has been published by the operators, it is manually updated and should be taken with a grain of salt.
23
24while there have been [recent pushes](https://docs.bsky.app/blog/plc-directory-org) to move plc.directory to an independent organization, details are still unknown about how the directory will be operated once transferred to the new organization.
25
26if you would like more info on the issues of the current model, [@merkletr.ee](https://bsky.app/profile/did:plc:ezhjhbzqt32bqprrn6qjlkri) has an [excellent article](https://merkletr.ee/fast) on the state of PLC.
27
28## how?
29
30this project will build a new server that will be backwards compatible with the current PLC implementation, however with a peer-to-peer system for synchronizing operations between different nodes and establishing a consensus on the state of the network's collective directory.
31
32the properties of how to establish consensus are not finalized, however a target is to have sub-second latency for large-scale amounts of operations per second with byzantine fault tolerant. the current idea is to expand on a [proof of concept](https://codeberg.org/xormetric/didfastpoc) previously created by [@tentacle.expert](https://bsky.social/profile/did:plc:zvinwh7vy4tjegch2hxvopdd).