With respect to #ActivityPub:

Simply, having now seen more into the guts of the process and how it is managed both historically and today, and understanding how the w3c works, I have no faith in their ability to define a clear consensus way forward out of the current set of problems.

Not "no faith in <timeline>" but no faith in the ability to define a clear way forward here.

This doesn't mean that someone outside of w3c couldn't define a better way forward, even one using AP, but w3c won't.

@hrefna I agree with you 100%

Do you see a path forward? FEPs?

Many here are so committed to “how things were” that it’s hard to talk about “how things could be”

I’ll happily sign on to something AP-adjacent (strict mode?) that lets us talk to Mastodon and Threads for now, and provides a richer overall UX among the implementers of the new protocol.

Any new group would have to be small, and filled with actual implementers, not industry reps and armchair architects.

@benpate @hrefna actual implementers is a critical component.

@jenniferplusplus@hachyderm.io @benpate@mastodon.social @hrefna@hachyderm.io I've held this belief for a while. FEPs might not be standardized by W3C but that *isn't* stopping us from implementing them and using them as if they were standard. A lot of standards have had things become standardized because they were common practice beforehand (look at C, C++ implementations). https://codeberg.org/fediverse/fep/src/branch/main/fep/9fde/fep-9fde.md I really would like to see this actually implemented and used.

@puppygirlhornypost2 @hrefna @benpate
This idea of putting together some structured way to describe how other servers should speak to you is one that's come up repeatedly. I'm not all that optimistic about it. I have no idea what the other party could or should do with that info. It's not a problem that's solvable at run time. At least not with the resources and constraints we actually have.

@puppygirlhornypost2 @hrefna @benpate
I get why people are doing it. It's the thing that would make AP an actual protocol. But only if it was done in advance, at design time. So that implementing the protocol meant producing and expecting those behaviors.

I don't think you can get from A to B with FEPs. You have to start fresh, with a successor protocol that actually defines those behaviors.

@jenniferplusplus @puppygirlhornypost2 @hrefna @benpate the issue with writing a new protocol instead of extending an existing one is that it isn't worth anything without anyone actually using it, and getting software developers to implement a completely new protocol instead of adding extensions to their current implementation is a much more difficult task

@lily @jenniferplusplus @puppygirlhornypost2 @hrefna

I agree. We must build on AP, not throw it away. The model that makes sense to me is “strict” mode. I know LitePub tried this, but I don’t know why it failed. Perhaps that’s a starting point for making a successful change.

@benpate @puppygirlhornypost2 @jenniferplusplus @hrefna what is strict mode?

@lily @puppygirlhornypost2 @jenniferplusplus @hrefna

"Strict" mode isn't a real thing -- it's just a fantasy of mine where we have actual definitions of what objects/properties are and how they're used.

Imagine something like "use strict" in Javascript applied to ActivityPub. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)

In the ActivityPub world, it would have saved me 80% of the code I wrote to get Emissary to Federate.

@lily @puppygirlhornypost2 @jenniferplusplus @hrefna

RIP LitePub: https://litepub.social

I think something like this is the most realistic way to simplify ActivityPub development, so it would be invaluable to understand why LitePub is now a ghost town.

If any of the elders here know the story of what happened there, this'd be a story worth telling.

Call it ActivityPub 2.1. It could start with some simple refactors to make all of our outbound messages rational and self-authenticating.

Really the biggest issue I've encountered is that the people who have been driving the bus when it comes to specifying the transfer of ActivityStreams between actors can only see the world through Twitter-coloured glasses.

ActivityStreams itself is what it is. Like HTML, it's a mess. Best practices will emerge (this is still happening) and eventually the spec will evolve. FEPs are a good step forward. Not perfect either, but it's a really just collecting the best practices and extension proposals and letting folks pick and choose. Some FEPs will turn out to be 'Recommended' and a few 'Mandatory'. The hardest part will be keeping brands and politics and corporations the hell away from messing with the Mandatory column.

LitePub was mostly a rejection of LD-signatures and started with an outspoken Pleroma developer. The spec itself was basically an incomplete rant that contained very little specification. By reading it, you had no idea what it actually did or how.

Which is OK, we've all rejected LD-signatures now and we've got an alternative (object proofs built on elliptic curve cryptography and a fairly simple data normaliser). The only thing you need to be careful with are floats (used by location-aware ActivityPub services). A few of the normalisers have issues with these.