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

@knt It is worth noting that accept rules only make sense if one wants an allowlist. For example:

An empty ruleset is equivalent to accept *

@helge Thank you, this is an important work. CanIUse.com but for Fediverse

@feld @frogzone @jeffcliff @p The way of Mastodon

@feld @frogzone @jeffcliff @p Projects that implement FEP-8b32 are already using Ed25519 keys (most notable of them is probably Hubzilla).

Some other developers are also considering Ed25519, either for embedded (FEP-8b32) or HTTP signatures (RFC 9421).

>Mastodon

Mastodon too: https://github.com/mastodon/fediverse_auxiliary_service_provider_specifications/pull/27/files#diff-2caefb0fa42bedec7feb2490de59da44151d6e5e98fbab4640495535229b079cR65

@p @frogzone @jeffcliff @feld Thank you, this is a useful feedback. I'll adjust the FEP

@p

>I'll try to make sure that we can interoperate without breaking the FEP semantics if possible, but some places, it's not going to be possible.

If you want to see how it all works in practice, there is @nomad

It is a Mastodon-compatible FEP-ef61 actor that is managed from a client.

>If it's a new protocol, I don't know why we're still doing a fragment for the key ID.

'ap' URLs resolve to ActivityStreams documents, and fragments are useful for pointing to specific sections within those documents. The URL you're citing is just an example, and implementers are not required to use fragments for key IDs (although that might be a good idea).

I shall change fragment ID in this example to something neutral.

>>Ed25519
>I'm using RSA keys so that it's easy to port myself from Pleroma. It is entirely possible that there is something I am missing and that we shouldn't be using RSA keys; maybe key algo is overspecifying.

Nowadays security specialists advise against using RSA (1, 2), and some modern standards do not support it (for example, there is no RSA cryptosuite for Data Integity, which we use for signing objects).

Fediverse needs to migrate to something else and EdDSA seems to be the best option (according to the rough consensus among fedi devs). Also, Ed25519 key size is very small, that's pretty cool.

>>/.well-known/apgateway
>I like this, but I wonder if there's a way around it without hard-coding another URL.

Yes, follow-your-nose approach is mentioned in "Discussion - Discovering locations". Existing implementations rely on well-known locations, but I think we can support follow-your-nose if needed.

>> The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type.
>This is actually objectively wrong. I don't know why this should be done rather than using the HTTP standard interpretation of "Accept:" headers. If the client doesn't include "application/ld+json" or "*/*", then you just return a 406. The way Pleroma/Masto do these things kind of shits on RFC 2616 and I really love RFC 2616.

But the FEP should say something about Accept header and media type, I don't see any way around that. The exact same requirement exists in ActivityPub spec.

How do you prefer it to be written?

>> Portable objects
>This part, I don't know how I'm going to manage this. The "attributedTo" being tied to the gateway URLs, and then those potentially changing

IDs are not supposed to change. You include this special query parameter ("location hint") when you create an object, and then it stays there even if you start using a different gateway.

Maybe there's a better way to provide location hints, I don't know. Existing implementations use compatible IDs (regular 'http' URLs with 'ap' URL appended), so not much thought has been put into pure 'ap' IDs.

>that's going to be a mess with content-addressed storage

How do you process Update activities then?

@frogzone @jeffcliff @feld

@frogzone Some are A, but most are C or D

@helge It would be useful to test for some combinations of tags too, for example Pleroma converts <h1>Title</h1><h2>Subtitle</h2> into TitleSubtitle, which is unfortunate for anyone who uses headings.

https://git.pleroma.social/pleroma/pleroma/-/issues/2413

@p @frogzone @jeffcliff @feld What is your current stance on FEP-ef61? Does it conflict with what you're doing in Revolver, or complement that?

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

Significant progress has been made since we last discussed it. Today there two implementations, Mitra and Streams, and they are partially interoperating.

@linos

https://codeberg.org/fediverse/fep/pulls/430/files

>Or use a custom attribute https://event-federation.eu/ns/#isVirtualLocation

+1

I think boolean attribute is cleaner than multi-typing. You can also duck-type location as a virtual location if url attribute is present

@frogzone @jeffcliff @p @feld Performance issues with IPFS were there from the beginning. Many hoped that Protocol Labs will fix them but that didn't happen, perhaps due to the inherent limitations of the protocol, or due to incompetence.
In any case, this is not a "controlled demolition". There was a shift to NFTs and then Filecoin around 2020, but I don't think that affected IPFS in a negative way

@helge @linos Good idea.
Inclusion of a new property is usually a safe operation, compatibility with other software is preserved. Change of type often breaks something

@linos Generally, applications should look for properties they understand, and ignore object types. This practice is known as duck typing. In case of location you can parse name and optionally coordinates. Now your peers can use any type they want, or skip it altogether - as long as name is present you will have something to work with.

@mischievoustomato Specially for you: Mitra v3.8.0. It should fix the issue with repeated posts.

I also made some optimizations, so overall performance should improve, but didn't touch the replies collection endpoint yet.

@tadano

@elvecio Your instance has been updated. You should be able to see new posts from nomadic accounts

@dimkr Mitra doesn't pull outbox automatically, but it can do that on request and I use this feature all the time.

@expertplus Right, but Mastodon can't dominate the market forever. It is expensive to run and its development is slowing down, so I think its days are numbered.
A new generation of Fediverse servers is coming. For example GoToSocial is relatively new but growing quickly and already has more than 1000 instances

@raphael IPNS shouldn't rely on DNS (maybe they started to use gateways to speed it up? I don't know).
There are ENS deployments on layer 2, in near future they can become very cheap, but you're right, it is difficult to use without relying on trusted parties.

My preferred solution is FEP-ef61 where we're piggybacking on DNS but the ultimate authority resides in cryptographic identity.

@raphael ipns:// URIs can be used as ActivityPub IDs because IPNS content is mutable. I don't know if there is an URI scheme for ENS but yes, that might work too.

@raphael As far as I know, "dereferenceable" doesn't mean that you need a domain name. It is required to dereference 'http' URIs, but other URI schemes may specify a different resolution algorithm that doesn't rely on DNS.