Email or username:

Password:

Forgot your password?
Johannes Ernst

Myself? I want to talk about what's on my #Fediverse wish list at #Fediforum, which is actually longer than the 8 points I blogged about here, but I gotta stop somewhere.

reb00ted.org/tech/20230425-w3c

17 comments
Johannes Ernst

Top of my #Fediverse wish list: A single-document Fediverse interop #spec that, when I have written the code for all that's in it, my code will interoperate in some basic fashion with all other #Fediverse software that has implemented this document.

Right now, I have to understand and sometimes reverse-engineer every single fediverse app, and that is simply not viable. Who has time for that? And do it again as soon as new versions come out. #ActivityPub is underspecified for this.

Ben Ramsey

@J12t @tchambers Instead of a document, a single test suite you can use to test your implementation would be nice.

Johannes Ernst

@ramsey #ActivityPub #test suite is actually number two on my list. There used to be one, but it's unmaintained and apparently not quite recoverable.

But we need both: a single spec, and a corresponding test suite. That should be the foundation.

Johannes Ernst

And #3 on my #Fediverse wish list is a branding program. If your product passes the minimal test suite, you get to put a sticker on it. Sort of like the "Validated HTML" logo we used to have when HTML was new, or the "Bluetooth" logo:

If a prospective user comes across a product displaying the brand, they will know it will interoperate. Geeks may not care, but IMHO it's really important for broader consumer adoption.

Mike Macgirvin
Implement ActivityPub and http-signatures (draft-cavage earlier than the final hs2019 draft, like maybe draft 10 or 11). Then you should be able to federate with generic ActivityPub services. Note: Mastodon is not considered to be a generic ActivityPub service. I'll cover those requirements a bit further down.

If http-signatures fail, some projects decide for you which headers need to be signed but there is no way to discover their signing requirements currently. Just sign everything you can. date, (request-target), host, and digest are the ones that some projects insist on. When in doubt, fetch an actor record or something and see what headers they sign for their own content and that should give you an idea what you'll need to include in yours.

Use rsa-pem public keys - I forget which PKCS# that was. 8? Elliptic curves and other more modern public key technologies don't federate well at the moment.

Then you just need to implement a few pages of Mastodon quirks and webfinger if you want to federate with that project.  This involves things like re-factoring your HTML so it looks decent when downgrading to plaintext, stripping out photos from HTML and adding them back in as attachments, making sure your comments mention the inReplyTo author so that Mastodon folks will get notifications, and making sure your mentions use the webfinger and not the displayName when conversing with that project. Or translate to/from your preferred mention display format like we do. Don't use 'Article'. Eugen poisoned it in an earlier attempt to exterminate HTML. And if you normally provide a 'summary' - you can't, as that's a CW in Mastodon. Mastodon mentions also include the initial '@' character in the link text. Some projects put it outside the link text. Best option: accept either/both because we'll never agree on it.

I think that's the important stuff.

Two things that trip up 90% of newcomers:

    Most ActivityStreams things can be a url, an object, or an array of objects. Just recognise all of them from the start so we don't have to file bugs. If your software can't use arrays internally, use the first entry and ignore the rest. Not ideal, but you will see posts with multiple actors and actor records with multiple urls and you don't want these breaking your server.
    
    Read the part in the ActivityPub spec about the Accept header. Then read it again. Don't send me an accept header of 'application/json' and expect me to send you an ActivityPub document. Maybe I will, maybe I won't.

And if you have any desire to federate with Facebook-like projects or those with a focus on privacy/permissions, send replies to the address or addresses in the replyTo field and to nobody else. If there's no replyTo, you can send it to whoever you want. Most of the time things will work just fine if you ignore this, and it isn't standard, but if you really want to federate with most of the fediverse -  you'll do it.
Implement ActivityPub and http-signatures (draft-cavage earlier than the final hs2019 draft, like maybe draft 10 or 11). Then you should be able to federate with generic ActivityPub services. Note: Mastodon is not considered to be a generic ActivityPub service. I'll cover those requirements a bit further down.
Dr. Quadragon ❌

@J12t
Also: posts archive migration/nomadic identity

Johannes Ernst

@drq that tends to be difficult in practice, if we are talking moving data from one app to another app (not just one app instance to an instance of the same app somewhere else). Which did you have in mind there?

Dr. Quadragon ❌

@J12t Of course, real world restrictions must apply, and migration must be between two same (Mastodon <-> Mastodon) or similar (Mastodon <-> Pleroma) engine instances.

Whatever the case, there MUST be a possibility for some kind of mobility beyond the simple contact list migration. Because some people are actually invested in thoughts and materials (a.k.a "content") they've put out over the years. And if they want to pack up and leave - for example, from a dying instance, they must be able to do it.

Your materials don't have to share your instance's fate.

@J12t Of course, real world restrictions must apply, and migration must be between two same (Mastodon <-> Mastodon) or similar (Mastodon <-> Pleroma) engine instances.

Whatever the case, there MUST be a possibility for some kind of mobility beyond the simple contact list migration. Because some people are actually invested in thoughts and materials (a.k.a "content") they've put out over the years. And if they want to pack up and leave - for example, from a dying instance, they must be able to do it.

Johannes Ernst

@drq if you “only” want full data migration between instances of the same app, isn’t that simply an app feature then, like a mastodon feature or lack thereof, rather than a fediverse feature?

Dr. Quadragon ❌

@J12t That's what we need to find out, I guess.

Zot network has no problem with nomadic identity. But that's probably because the only engine on there meaningfully is Hubzilla, AFAIK.

Johannes Ernst

@narF Yes I'm aware. There are certain things FEPs can do, and cannot do. Just writing a document has generally never solved much :-)

narF 🎲

@J12t Oh ok. I don't know, I'm not a dev. I just thought it looked cool.

At the very least, I hope all people who want to improve the specs should talk to each others! 😄

Johannes Ernst

@narF The problem is not specs. The problem is common movement forward. A spec becomes valuable if many people implement it and it enables interop between many pieces of software. Everything else is just dead trees (or maybe bits ...)

narF 🎲

@J12t Agreed. I hope that most Fediverse project are aware of these FEPs and will attempt to implement them! :)

Go Up