@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.
-
@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).
-
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…
