Notices by silverpill (silverpill@mitra.social)

@trwnh

>What’s the difference between a “quote” and a “link preview”?

I think there is no difference. Quote is simply an enhanced preview.

@suno I think Tuba may identify Mitra as Pleroma. Try again with Mitra 3.10.0, editing should work better now.

Drag and drop is also available now in mitra-web 3.10.0.

@elvecio This is probably a bug in one of the libraries I'm using. I will try to update to a newer version, but that will take some time

@japananon The code expects social address in the @username@instance format, otherwise it seems to work similarly to Twitter address extractor.

The wallet should hit this API endpoint on your server when it looks up the user: /api/v1/accounts/lookup (this path should appear in nginx logs).

I pinged them a couple of days ago about this issue, but haven't heard back yet.

@raucao @Haydar This is a common failure mode of security specialists. They make perfect the enemy of the good, and start building or promoting systems that are secure but deficient in some other way: too centralized, or too difficult to use, or too difficult to implement. And ironically, those defects often make their systems less secure.

@pfefferle @nutomic @julian @angusmcleod @johnonolan

Yes, it should be an activity

https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md#the-announce-activity

@gabriel @hazlin

>In short, you bootstrap a "from nothing" currency based on extending others "credit".

Sounds like Circles https://joincircles.net
I think it failed to get any traction

@sun Is it like CORS for ActivityPub's origin-based security model?

@sun Okay, thanks for letting me know. Just to be clear, I'm not against did:web, it can be one of the blessed methods and I'm willing to support it in Mitra. I demoted it only because I thought no one is working on it.
And generally, I'm open to feedback. FEP-ef61 is a work in progress, there are unsolved problems (collections are difficult), and some parts of it will certainly change as we get more feedback from implementers. But not did:key compatibility - this part is very important for me.

@sun Reliance on a domain name is not acceptable for me, so I made did:key support a requirement. But FEP-ef61 doesn't exclude did:web or any other DID method. Actually, supporting a wide range of DID methods is the second primary design goal after did:key compatibility.

I can't simply say that implementers are free to choose any DID method, because that would lead to 10 non-interoperable implementations. Some methods have to be "blessed", and right now only did:key has that status. A number of other methods are under review: did:web, did:dns, did:tdw and did:fedi.

If you are interested in using did:web with FEP-ef61, I will make it recommended (and that means it will be supported in Mitra).

@elvecio The certificate returned by your server is for aprendendofisica.net, not for unio.diversispiritus.net.br, and apparently this is because my HTTP client doesn't properly do SNI. I'll try to fix that

@sun Do you use FEP-ef61? I just demoted did:web from a recommended method to a candidate, but can bring it back.

>webauth

I haven't heard about it. Did you mean webauthn?

@eltenso

Yes, but I've seen error messages about the certificate, so it could be a one-way federation

cc @giacelvecio @elvecio @elvecietemergency

@erlend Looks interesting, thanks for sharing. However, it is not clear how users are protected from impersonation by servers, because initial DID document is generated there and user's signature is added later.

@gabriel Someone is working on a comparison table for servers, but there is not much data: https://evant.github.io/mastodon-api-compatibility/

@cy @jupiter_rowland

Proof of concept exists: https://codeberg.org/silverpill/fep-ae97-client

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447

The most important change here is a switch from FEP-c7d3 to FEP-fe34. An algorithm for computing origin of a DID URL has been specified, so now it is possible to do this:

is_same_origin(id, proof.verificationMethod)

#NomadicIdentity #fep_ef61

@helge These two protocols may seem very different, but it was discovered that they are fundamentally the same. This is what FEP-fe34 really is: a Grand Unified Theory of Fediverse.

Same-origin policy applies to both HTTP URLs and DID-based identifiers. In the first case authority is derived from a DNS name, and in the second case it is derived from a DID, but otherwise the logic of authentication is similar.

Yes, servers still need to support DIDs and integrity proofs in order to understand what is going on, but mechanisms like reply controls can be designed in a way that works with both kinds of authorities.

For example, Conversation Containers are compatible with FEP-fe34, so I expect them to work in nomadic Fediverse too.

@cakewallet Hello, could you a look at this issue? https://github.com/cake-tech/cake_wallet/issues/1141

@helge

>First observation: The current Fediverse cannot handle this in any meaningful way.

It can be done with FEP-ef61 + FEP-ae97. When FEP-ae97 client sends a message to one server, that server copies received message to other servers where actor is hosted. Other servers may then deliver message to followers (though that would be redundant because followers collection is the same everywhere).