With respect to #ActivityPub
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] Can we replicate how that breaks power delivery by making it invalidate HTTP Signatu.. oh fuck. yeah im seeing a problem here
-
@puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
*Depending on the specific changes...
Of course HTTP signatures throws a monkey-wrench in any migration plan (not to mention "Authorized Fetch")
But all of this is academic until we have a specific list of changes. I'm pretty certain (depending on the list) that we could chart a smooth-ish migration path forward.
I'm happy to write up my own thoughts for others to pile on to. We have to start somewhere, yeah?
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] also although it might sound nihilistic to list out every potential problem it is actually worthwhile to come up with a list of "potential issues" to workaround.
-
@puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
So, apparently I'm collecting a list of #ActivityPub pain points, now.
(shit)
What's your top ten list? I'd love to compare, and make sure I collect a complete picture, even if I don't have a good solution to the problem just yet.
-
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. -
-
@benpate @puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
One of my pet peeves: Guarantee that the the "fetch"-based sequence of activities is the same as the "POST"-based sequence. In other words, guarantee that if I missed receiving a POST, I can recover by browsing the outbox.
-
@benpate @puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
1. Remote server interactions need a solution that is invisible to user
2. Account migration to other servers needing to be standardized beyond just Mastodon’s technique
3. Reply moderation needed - including hide reply to all
4. Simple solutions for Auto backfill of missing replies, old follow counts, etc -
@benpate
Here's one
Why can i see that you have two replies but i can't see those replies? -
@CassandraVert Yep, great example. I think this is called something like "phantom replies" or "dropped replies"
And, I think the "Threaded Discussions Working Group" is working on something for this, but (as always) support may be spotty.
I've read several replies from people saying versions of "this is just because of the nature of 'Federation', so deal with it" but no other self-respecting social network would allow this behavior.
We're building ONE system, not many interconnected systems.
-
@tchambers @puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
Thank you, and yes. Excellent issues to fix.
I'll add these to my list, with some placeholders for "Proposed Solutions"
--
I can't stand when people sit on the sidelines and gripe about my work, but don't propose any way out of the problem, so I'm determined to not do this here.I have plenty to gripe about, but feel like we should at least say what we'd do about it -- even if nobody else is listening
-
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily
(Long reply follows, possibly breaking your client implementation?)
- Lack of reference implementation. A spec without a reference implementation or usable test suite hands control of the spec to the largest implementer.
- Lack of easy extensibility. A successor needs a clearly documented capability for extensions.
- Lack of opinion on implementation. This is a controversial one, but leads to implementations that are spec-conformant but not interoperable. The spec should provide a baseline set of operations that may/must be implemented upon receiving a message, with a set of expected responses.
- Feature discoverability. When your protocol allows for wildly different implementations, feature discovery is essential to allow interoperability. This allows servers to negotiate for the largest implemented subset of features instead of defensively assuming the smallest.
- Trust at the server level. A server verifies actors it owns, no individual certs. The verification mechanism must be baked into the spec and not left to implementers.
- Batching.
- Doesn't utulise HTTP effectively. ActivityPub mandates HTTPS as a transport protocol but does not mandate use of HTTP features such as response codes. This is a must-fix for operational scaling.
- Client API. C2S is almost impossible to implement. A replacement should be an optional, lightweight, minimum-surface REST API. -
@benpate @puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily A pretty solid list on https://github.com/mastodon/mastodon/issues?q=is%3Aissue%20state%3Aopen%20sort%3Areactions-%2B1-desc ! (It’s the mastodon issue list, sorted by upvotes)
Most of my personal biggest pain points are covered in that first two pages of issues.
-
@sebinthestars @puppygirlhornypost2 @hrefna @jenniferplusplus @lily
These are all great issues to address. I may have some specific follow up questions when I get back to my desk.
-
@Brendanjones @puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
Thank you! There’s some great ideas in this post, and they’re already nicely documented.
I’ll sift through it to find the issues that seem addressable, and add them into the document I’m making.
When I get it posted, could you double check my work to make sure I’ve captured everything correctly?
-
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. -
@mikedev Thank you for the history lesson! The LitePub website has just enough information in it to let me pour all of my hopes and dreams into it, with no pesky details to burst the illusion
-
-
@hrefna we would be very happy to join such a working group
-
@hrefna we'd like to propose just making a coalition of the willing without any overarching organization, and then having meetings and longform discussions in the way that a standards body does
