@smallcircles@mariusor@evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.
@mariusor@smallcircles@evan C2S has client-side and server-side aspects (different, but overlapping, behavioral requirements, etc.). Both sides consume *and* produce AP data (pull and push for S2S, currently only pull for C2S). Fetching AP data (URI dereferencing) is common to both C2S and S2S.
@mariusor@smallcircles@evan No animosity here. However, I’m not sure how to explain it more clearly. I’m referring to C2S as described in chapter 6 of the ActivityPub specification (and the conformance profiles in Section 2.1). It sounded to me like you’re using a more general definition of “client”, which is fine, just different in significant ways (if it only dereferences and renders AP data).
@mariusor@smallcircles@evan I’m not sure I completely follow. A timeline is ordered by time. I agree that an unordered collection could be sorted by time to create a timeline. The AP OrderedCollection “stream” is a kind of rigid presorting that anticipates what an AP client would want. However, I also agree that even those could be reordered (by time or otherwise) and/or filtered in the client to provide custom views of the activity stream.
@mariusor@smallcircles@evan Yes, it can be done in the client or the server, or both. I’d like to see an interoperable way to define custom timelines (a kind of user-defined timeline algo) that the server maintains. A Mastodon account list timeline is a super simple version of it, but AP could provide something much more powerful (advanced filtering, merging, ranking, …). Ideally, these could be shared and customized further on the client side.
@mariusor@smallcircles@evan I think you read something other than what I wrote. 😀. I’m describing *user-defined* timelines where the heavy lifting is done in a server. That server would be (or could be) *general purpose* and not specific to an activity domain. I definitely wasn’t suggesting a monolithic, tightly-coupled client/server architecture. I want my timeline definitions to be portable and interoperable.
@smallcircles@evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.
I'm curious what other devs think about this. If an actor posts an C2S #ActivityPub Create/Note to the outbox, what would you think if the object created by the server was a different type (e.g., Article)?
@pfefferle I haven't been working on Flowz for the last 6 or 7 months, but I plan to dust it off and continue work on it given the recent interest in the ActivityPub client API. I subscribed to the github issue and will track that. Is the WP implementation ready for testing?
@silverpill Those workarounds for the undermined extensibility don't negate my point and will not generally interoperate. According to the ActivityPub book, "One point to note is that correctly parsing and interacting with AS2 objects with extended properties requires a JSON-LD-aware parser." I agree this isn't absolutely true (in special cases) but try sending expanded "toot" context term URIs and see how well it works 😉 (since all servers AFAIK expect those terms to be compacted).
Here's an idea. What if we extend #ActivityPub C2S (C2S++?) with a minimal set of features (FEPs) to provide a reasonable (or even excellent) UX? Along with servers that already support C2S, we could write an external protocol adapter from C2S to the Mastodon client API to increase the number of users that could potential use a C2S client. The C2S API would be general, but the UIs could be domain-specific (microblogging, media sharing, long-form, etc.). Who's with me? https://www.youtube.com/watch?v=6eX3fiQLo84
@hosford42@mapache@j12t@tchambers@tommi Moderation is also an issue with email-based "overlay" communities (spam and abusive behavior on mailing lists). The challenges seem roughly similar.
@j12t@tchambers@tommi The ActivityPub network (Fediverse) is often compared to email. I know it's a dubious analogy, at best, but people don't typically pick email servers (or email service providers) based on "community". However, communities still form as an "overlay" social network through mailing lists, newsletters and so on. Why can't an "instance" simply be an ATA (Activity Transfer Agent) and clients be AUAs (Activity User Agents) with the ability for any AUA to work with any ATA?