@benpate@dansup I believe the primary reason there are no widely-used C2S user-facing clients (vs testing tools) is that the standard C2S API is not sufficient for a decent UX. If you compare the Mastodon client API with the AP C2S API, there's a significant disparity in features.
@blog Yes, it’s a shame that Fedi public keys for HTTP signatures are not publicly accessible in authorized fetch scenarios. That doesn’t make much sense to me. The reason for it (fragment-based key IDs in Mastodon) is obscure and seems arbitrary to me. The fix is relatively easy, but I don’t see much motivation to fix it.
I’m beginning to wonder if the email mental model some people suggest for #ActivityPub is a serious hindrance to understanding the concept of a federated, decentralized social graph.
@trwnh@devnull So ActivityPub is basically just WebMail? ;-) Where does the social graph and applications (far) beyond twitter-like clones fit into this view?
If the #ActivityPub community effort to define problem domain-specific AP interop profiles proceeds past the discussion phase, some initial profile candidates are: microblogging, video sharing, image sharing, audio/music sharing, media review (books, movies, etc.), and event planning. Each of these has existing implementations and represents a specific AP use case. In the longer term, other profiles, like for forge federation, could be added as implementations evolve and mature.
The #ActivityPub sharedinbox is a strange concept. It's an inbox without an actor. I suppose one could think of it as being backed by an implicit, non-conformant (no outbox) actor-ish thing that routes messages to other inboxes. There's no requirement that there's zero or one sharedInbox per server. A server can have any number of them. You could have one per set of actors in a Group or Organization, for example. But then the sharedInbox would an Group/Org actor-specific inbox. 🤯
@smallcircles@evan One of my concerns about the FEP process is that it is actually too tightly coupled to SocialHub for the purpose of FEP discussions. It's natural to comment on an FEP "issue" in the issue tracker. The current approach means the discussion is sometimes fragmented between SocialHub and Codeberg. I think SocialHub is very valuable. I'm just not convinced this is the best way to use it for FEPs.
@smallcircles@evan I've already discussed it on SocialHub. I personally have benefited greatly from seeing W3C and Mastodon discussions about issues in the issue comments (same for many other projects). But that is a tangent. My point is that SocialHub is a required element of the current FEP process. (CORRECTION: SocialHub is not explicitly required. It's just a strongly recommended convention. FEP discussions can officially happen anywhere.)
@smallcircles@evan Ah, thanks. I see now it's not explicitly required by the process meta-FEP. I had a different impression based on related discussions on SocialHub. So the FEP process allows the FEP discussions to happen anywhere: SocialHub, the FEP issue comments, the SocialCG mailing list, Matrix, here, any combination of these, ... good to know. 😉
@smallcircles The data is literally "linked data". Although there are other options for working with distributed linked data than using Linked Data tech, I'm wondering what alternative you have in mind. Many developers use ad hoc implementation-specific techniques to manage it, but it's not clear to me that this is an improvement over LD.
@helge@hrefna Rephrasing the question as "Why does ActivityPub not define a concept of ownership?" may be better. The other issue with the vague reference to "owned by the server" is that "server" is not defined anywhere. What defines the scope of server ownership? Maybe a URL prefix (to support multi-tenant implementations)? Or attribution to an "application actor" (or "tenant actor")? It's definitely an underspecified topic.
One of the challenges with #ActivityPub targeting is that the targeting properties (to, cc, bto, bcc, and maybe audience) conflate inbox delivery, interaction authorization, notification policies, and visibility (and probably more). This is a broad range of somewhat orthogonal behaviors and the limited guidance in the specs for them only makes it more challenging for AP devs.
American living in Southern France. Developer of the FIRM server platform. I'm interested in #computers, #SoftwareDevelopment, #SemanticWeb, #osint, #DistributedComputing, #pkm, #HomeAutomation, #PhysicalComputing, #iot, #rpi, #esp32, #hiking, #traveling, learning #french and lots of other stuff.