Notices by silverpill (silverpill@mitra.social), page 48

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

@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.

@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

@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

@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.

@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

@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.

@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

@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:

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

@erlend

@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.

@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)

@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.

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

@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

@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.

@erlend

did:web is a standard with multiple implementations

did:plc is single implementation deployed on a single server

@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

@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.

@jenniferplusplus @mikedev If someone sends you an activity, you can look up actor, attributedTo, inReplyTo and other referenced objects on their server because they should already have them in cache.

Once you have an actor object, you can start interacting with its clones listed in aliases property.

Publishers can also provide location hints in query parameters. Take a look at "Actor IDs" section: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#actor-ids

@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).