As far as I understand, most (all?) fediverse #ActivityPub software does not use the Client-to-server protocol from the specs (https://www.w3.org/TR/activitypub/#client-to-server-interactions) but rather use custom APIs instead.
ActivityPub Test Kategorie
62
Beiträge
19
Kommentatoren
2.0k
Aufrufe
-
@strypey@mastodon.nzoss.nz @naturzukunft @smallcircles @skyfaller @hugh @bob There are other servers that implement C2S support (ActivityPods, Vocata, onepage.pub, ...). Lack of servers implementing C2S is not the problem. See the many other issues described in this thread for examples of why one can't built an *interoperable* AP C2S client with features a typical user would expect.
@steve @naturzukunft @skyfaller @hugh @bob
@evanGood thread!
I wanna collect C2S compliant projects here: https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130I'm planning updates to the 4 fedi-related https://delightful.club lists and reorganising them. Have a humongous maintenance backlog too.
In this reorg I want to highlight the more interesting, unexplored and innovative directions that our fediverse may be evolving to.
The other day I had discussion on 2 top categories for fedi apps list: https://thoresson.social/@anders/114433900582811705
-
@hugh@ausglam.space it's because clients can't make any assumptions about ActivityPub data using the C2S model. They have to perform full client side parsing and linking, then figure out some way to display this graph structure of data they've been given. The fact of the matter is that ActivityPubs design is overly broad, and no client could account for this. So, instances implement an API offering a simple, watered down format, plus the benefit of having stability even if the software moves to another federation protocol down the line.
There's also the matter that almost all ActivityPub implementations do not store posts in their database as JSON-LD, instead they unmarshal the data from it and store it in a concise format. Reconstructing it for the purposes of C2S would be inefficient and clunky. -
More interesting angle to your question, maybe why asked, is to "reimagine forums" in our new age of social networking.
Yesterday I had a discussion about https://blocks.githubnext.com "Reimagine repositories". Great ideation starting point. What is a repository actually? Container of a solution? Or .. what?
Maybe a forum is single-person software, attached to the social graph of the social web? Tapping into activity streams and knowledge bases. To 'slice' our personalized community views?
@smallcircles@social.coop personally, I feel that asking people to post or continue a discussion on another platform is a roadblock that shouldn't need to exist.
You can't do it on Discourse, but in NodeBB you can "categorize" a topic, even if it came from the microblog-fedi. Similarly to how you can import a reply tree into another Mastodon instance. That's the difference, that the software should support something like this, although I get that that's not always important to every piece of software.
Things get a little more confusing if a topic is already categorized, like a Lemmy/Piefed post in a community, so I expect some of that to change in the coming months.
End of the day it would look something like "cross-posting" as currently exists on the threadiverse.
-
@julian I like the general direction, and it is very promising. Liking too the collab between NodeBB, Discourse and Lemmy in this regard. Very important that for interop sake. Thank you for all your efforts on the forum taskforce!
-
@skyfaller Well one person’s “under-defined” is another person’s “flexible and simple”. If people get their heads out of micro-blogging it becomes clearer why a more rigid definition becomes limiting, IMO.
@hugh @skyfaller part of the problem with how “underdefined” it is, is that we’re not talking about the big picture being there but mostly in need of filling in the gaps. we’re talking about “there is no agreed-upon authorization framework” levels of “underdefined”.
the other part is that it presupposes a wildly different topology than what fedi adheres to. the most natural interpretation of “client” is not something like Tusky. the AP client would be Mastodon itself as a client of an AP server
-
@hugh @skyfaller part of the problem with how “underdefined” it is, is that we’re not talking about the big picture being there but mostly in need of filling in the gaps. we’re talking about “there is no agreed-upon authorization framework” levels of “underdefined”.
the other part is that it presupposes a wildly different topology than what fedi adheres to. the most natural interpretation of “client” is not something like Tusky. the AP client would be Mastodon itself as a client of an AP server
@hugh @skyfaller here, the AP server handles storage and delivery. i could then use mastodon/pixelfed/etc as clients to GET/POST against my outbox/inbox as needed, basically treating the AP server as a database of sorts, as well as a mail server of sorts.
most implementations of fedi are not like this and do not want to do this. they want to be monoliths. monoliths are “easy”. the will to abstract away social activity storage and delivery is largely not there.
-
@hugh @skyfaller part of the problem with how “underdefined” it is, is that we’re not talking about the big picture being there but mostly in need of filling in the gaps. we’re talking about “there is no agreed-upon authorization framework” levels of “underdefined”.
the other part is that it presupposes a wildly different topology than what fedi adheres to. the most natural interpretation of “client” is not something like Tusky. the AP client would be Mastodon itself as a client of an AP server
Yes that's what has become clearer to me as more people outline what they think the gap is (surprise: they don't all agree on that). There's a chasm between what the people writing the spec were imagining, and what most projects that use AP are trying to do. While the lack of detail on authorisation is a pretty major problem, it now seems to me that to a fair extent the issue is more a mismatch between the conceptual model of the ActivityPub spec (thick clients doing the work, with servers passing messages between them) and what most fediverse projects are trying to do (tightly-coupled server-client apps that talk to each other).
-
@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.
probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?
-
@julian @smallcircles i think i may have said this to you before, but the precise pain point is less “i had to go to another website” and more “i can’t do anything on that other website”. the web is by design already federated in a sense, but we have built a second-layer nested/virtualized browser-within-a-browser. https://www.devever.net/~hl/webappcoupling
-
Yes that's what has become clearer to me as more people outline what they think the gap is (surprise: they don't all agree on that). There's a chasm between what the people writing the spec were imagining, and what most projects that use AP are trying to do. While the lack of detail on authorisation is a pretty major problem, it now seems to me that to a fair extent the issue is more a mismatch between the conceptual model of the ActivityPub spec (thick clients doing the work, with servers passing messages between them) and what most fediverse projects are trying to do (tightly-coupled server-client apps that talk to each other).
@hugh @skyfaller ah yeah, in a socialhub thread i called it an “impedance mismatch” and i mostly stand by that — fedi wants to do more than just sending notifications to inboxes, and reading notifications from those inboxes.
the other side of this is that the notifications themselves are often consumed as JSON-RPC instead of being kept around as bona fide resources. when’s the last time you stored a raw HTTP POST request/response message on disk? all fedi cares about is side effects…
-
@julian @strypey one wonders if it would perhaps be more expedient to just do the identity bits and have the data live on B rather than ferrying it back to A.
probably what’s needed is a framework for tracking which resources are equivalent to each other. say i crosspost from my website to a forum. the post exists as two resources, one on each site, even though they are the “same” post. maybe as:alsoKnownAs can help here?
@trwnh@mastodon.social the idea behind B delegating actions for A to carry out is that A is the actual owner of the user, and can sign it accordingly (per same origin security)
There are object proofs but those aren't exactly easy to implement...
-
@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.
in other words, imagine identity server I, which is used to sign in on both A and B.
you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.
-
@julian yeah, A owns the user account on A, but B might have a separate user account on B. the same logical person might control both user accounts. if identity was federated, the same credentials could be used to sign into both user accounts equally.
in other words, imagine identity server I, which is used to sign in on both A and B.
you make a post P1, which is published as R1a on A, and R1b on B. what participants need to know is that both R1a and R1b are authentic.
@trwnh@mastodon.social but why must a separate account be made? Account fragmentation is yet another unsolved problem because the new user on account B is functionally useless: no followers, etc. and the content isn't automatically available to the followers of the user on instance A.
