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

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

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.

@helge @jenniferplusplus The URL library I'm using thinks something is a port number. Don't know about others

See also https://github.com/w3c/did-core/issues/556

@Hyolobrika Private property is not particularly decentralized because it is enforced by a centralized entity (he talks about that in another part of the article). The only truly decentralized alternative is allocation via physical conflict, and perhaps ironically it also fits into his definition of credibly neutral: the outcome is not specified, the mechanism is publicly verifiable, simple and doesn't change often (doesn't change at all).

@mikedev @deadsuperhero Synchronization definitely needs more thinking, but the general idea has been laid out in "Inboxes and outboxes" section: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#inboxes-and-outboxes

When actor creates an activity, it should be sent to all servers where outboxes of actor's clones are located. This can be done by a primary server, or it can be done directly from a client.

@fentiger @helge We can use custom URI scheme instead of DID URLs. I included this option in the proposal:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#url-scheme

However, my URL library doesn't parse it at all and says that z6Mk... is not a valid port number.

@greyarea @fentiger Yes, you're right. I found the issue where this behavior was discussed:

https://github.com/w3c/did-core/issues/556

>the design of DID URL syntax was patterned after URN syntax
>Parsing of the rootless path into the segment-nz component and the *( "/" segment) component must be done "manually" by the parser as with URNs.

Yet another FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/283

Replacing DID URLs with resolver URLs is now recommended for MastoPub interop. My implementation experience shows that this approach is better than alternatives.

FEP-ae97 is not required anymore, implementers can use server-owned keys.

#fep_ef61

FEP-ef61 resolver endpoint:

https://mitra.social/.well-known/apresolver/did:ap:key:z6MkjtdL1hhAtJDRTti4JZtjGVkMiqbrQWhLQjK8wV4neCvS/objects/018e1080-3792-c4f9-69b0-a6a0f609f94e

This service is a very important part of FEP-ef61. It connects the regular web with the web of signed AP objects, similarly to how IPFS gateways provide access to IPFS objects. However, unlike IPFS objects, AP objects are mutable.

Resolver URLs and DID URLs are equivalent, and implementations that support FEP-ef61 will simply strip the resolver part when they encounter it.

@mariusor @mikedev webfinger adds a layer of indirection, ObjectID -> JRD -> Object

However, there's a proposal to allow skipping JRD: https://socialhub.activitypub.rocks/t/using-webfinger-to-resolve-the-actor-for-an-acct-without-parsing-for-a-self-link/3941

I would still prefer a separate resolver endpoint because DID URLs don't need to be URL-encoded in this case and the resulting HTTP(S) URL is shorter. (By the way, the term 'resolver' was borrowed from "Decentralized Identifier Resolution (DID Resolution) v0.3" specification https://w3c-ccg.github.io/did-resolution/)

@mikedev The path can be different, for example it can be /ap/ instead of /.well-known/apresolver/.

Though with /.well-known/apresolver we can be sure that it is not used by any existing AP server.

#Mitra v2.13.0

https://codeberg.org/silverpill/mitra/releases/tag/v2.13.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v2.13.0

- Notifications about emoji reactions.
- Public posts can be exported in FEP-ef61 format (exported objects are not very useful at the moment, but it's a first step towards data portability)

@julian @jupiter_rowland These classes are defined in microformats standard, so they are not Mastodon's invention and other implementations might also look for them when generating previews. Mastodon has documentation page with explanations: https://docs.joinmastodon.org/spec/microformats/

@julian mention links should have u-url class (and maybe mention too), and they should be wrapped into <span class="h-card"> element.

hashtags should have rel=tag attribute

@newt

Another funny Fediverse trend is cancelling projects in favor of "approved" forks

>Popular fediverse projects: Mastodon, Akkoma, Firefish.

@smallcircles @helge @manyfold

For domain-specific projects like Manyfold - yes, it's pragmatism vs best practice. You get better interop if you choose Note.

For general purpose implementations, it's both (and I consider microblogging services general purpose, similar to RSS feed readers). Property based approach works really well for processing incoming Create activities. If object is attributed to an actor and has content, microblogging application should display it as a post, I don't see any reason to do otherwise.

In other situations, however, type based approach is preferable: activities, tags, attachments.

@manyfold @helge The choice of type depends on your priorities. Note is supported by Mastodon and other popular implementations, Document is only supported by some. Custom type will likely be rejected by almost everyone, but I think your use case justifies a new type, and generally property-based interop is worth pursuing because it will benefit everyone.

@nimda @pseudocute Local emojis should have empty hostname field in the table.

This site can be useful too: https://emojos.in/wizard.casa

@manyfold I think property-based interop is often better than type-based interop and that the former should be more popular among developers. It is easier to design new applications this way. Unfortunately, today many servers would refuse to process objects of unknown types, even if all properties needed for conversion are present. You can see how different objects are processed in this table:

https://funfedi.dev/support_tables/generated/object_types/

(made by @helge)

Mastodon is particularly restrictive. There's an open issue though: https://github.com/mastodon/mastodon/issues/24079

@manyfold

A couple of things that stand out:

>Servers that do not support the 3dModel object type will reject the Activity; in this case, the 3dModel will be sent as a Link instead, containing the canonical URL of the model’s web page, and the 3D preview will not be included.

Alternatively, you can send same objects to everyone but make sure that they has content and attributedTo properties. This will allow other platforms to display them as posts even if they don't know about the 3dModel type

>Our Actor objects are just as defined in the ActivityPub standard; they are mapped to our instance Users.
>Only activities from actual real users of an instance are federated

It's better to use standard types for actors. In your case Person seems to be appropriate.