I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
59
Posts
9
Posters
20
Views
-
It does not need to be that way. I am quite happy after all (after being initially frustrated) by how #ATProto has disrupted things, and opened the eyes of devs in the #ActivityPub ecosystem that we must act or lose out (stay niche, which may be fine too) to the Atmoshpere and how it enables devs to focus on service and product delivery instead of low-level wire plumbing and continuous breakages.
ATProto also shows the way that we can now follow on the #fediverse to catch up again: cocreate a similar robust basis for people to build on. #Bluesky had the advantage of a greenfield start and dedicated team unburdened by past decisions. And they build this whole Lexicon system and ways to introspect functionality.
We can do that too, solve the #LinkedData conundrum, and create an extensibility mechanism that allows devs to focus on service modeling. The more introspection this mechanism allows for, the less design-by-consensus is required, easing expansion to new domains.
@smallcircles @deadsuperhero I've quietly been borrowing ideas from AT Protocol for ActivityPub:
- declaring moderation actors
- supporting content labels (first party abd third party)
- looking at how custom feeds, DIDs and other tech may translate across -
@smallcircles @deadsuperhero I've quietly been borrowing ideas from AT Protocol for ActivityPub:
- declaring moderation actors
- supporting content labels (first party abd third party)
- looking at how custom feeds, DIDs and other tech may translate acrossI was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).
The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.
All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.
-
I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).
The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.
All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.
@smallcircles @deadsuperhero not just that, but if we evolve our understanding of what AP *could* be beyond what Mastodon *needs* AP to be.
-
Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).
I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.
If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.
There's so much confusion on "where does the protocol end vs. where does my app design start".
SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.
-
Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).
I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.
If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.
There's so much confusion on "where does the protocol end vs. where does my app design start".
SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.
-
@smallcircles @julian @deadsuperhero we call them collections.
Except when they are called other names instead ;p
A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).
Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.
For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.
-
@smallcircles @julian @deadsuperhero we call them collections.
@evan@cosocial.ca gosh I can't imagine assigning Add and Remove activities for a "popular" collection. It changes so often that it seems a waste of resources to try to track it.
Dynamic Collection?
Or as @smallcircles@social.coop said, even just light algorithmic ordering in a timeline makes stuffing it into a collection unwieldy.
-
I might not understand what we're talking about.
@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.
-
I might not understand what we're talking about.
@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
-
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
-
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
@smallcircles@social.coop I feel personally called out for this 😛
-
No need to, I didn't call you out :)
I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.
No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.
We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..
https://discuss.coding.social/t/major-challenges-for-the-fediverse/67
-
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.
GoToSocial currently broadcasts an `Accept(Note)` to let followers know a reply has been accepted (see https://docs.gotosocial.org/en/latest/federation/interaction_controls/#broadcasting-accepts-for-the-benefit-of-third-servers). We'd want to add an inverse for revocation, which would be `Undo(Accept(Note))` imo.
I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?
-
@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.
GoToSocial currently broadcasts an `Accept(Note)` to let followers know a reply has been accepted (see https://docs.gotosocial.org/en/latest/federation/interaction_controls/#broadcasting-accepts-for-the-benefit-of-third-servers). We'd want to add an inverse for revocation, which would be `Undo(Accept(Note))` imo.
I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?
@julian@fietkau.social @julian@activitypub.space @smallcircles I like Accept and Reject but @trwnh is pretty insistent on Add and Remove so I defer to them.
-
No need to, I didn't call you out :)
I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.
No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.
We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..
https://discuss.coding.social/t/major-challenges-for-the-fediverse/67
Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc.
Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. #ActivityPub et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices.
I would have power tools like #EventCatalog and methods like #EventModeling.
-
@julian@fietkau.social @julian@activitypub.space @smallcircles I like Accept and Reject but @trwnh is pretty insistent on Add and Remove so I defer to them.
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles personally i think three things happen generally, which could each be described by their own activity in succession:
1) the original Activity is posted.
2) you can Accept or Reject the Activity.
3) as a result, you can Add or Remove the Activity to the corresponding AP collection.this holds for Like and Announce 1:1. Follow we currently Add the Follow.object instead, but i think we ought to store the actual Follow activity in a follows collection.
-
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles personally i think three things happen generally, which could each be described by their own activity in succession:
1) the original Activity is posted.
2) you can Accept or Reject the Activity.
3) as a result, you can Add or Remove the Activity to the corresponding AP collection.this holds for Like and Announce 1:1. Follow we currently Add the Follow.object instead, but i think we ought to store the actual Follow activity in a follows collection.
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles of course follows are a bit more stateful and complex, so it can be argued that we should actually allow for richer subscription management, similar to when you open a dashboard and manage which email notifications you want to receive. the subscription could be reified as a Follow activity, but the side effects and semantics are not exactly the same with what's in AP right now. (AP doesn't have a way to remove a follower; masto uses Reject without Undo Accept)
-
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles of course follows are a bit more stateful and complex, so it can be argued that we should actually allow for richer subscription management, similar to when you open a dashboard and manage which email notifications you want to receive. the subscription could be reified as a Follow activity, but the side effects and semantics are not exactly the same with what's in AP right now. (AP doesn't have a way to remove a follower; masto uses Reject without Undo Accept)
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles and then there are replies, which in fedi currently require deep introspection of a Create.object.inReplyTo, which is information that may not be immediately available to you. so it leads to the unfortunately complicated situation where you don't actually know when you received a reply, because there is no Reply activity to be used as a notification -- you have the side effect without the activity.
-
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles and then there are replies, which in fedi currently require deep introspection of a Create.object.inReplyTo, which is information that may not be immediately available to you. so it leads to the unfortunately complicated situation where you don't actually know when you received a reply, because there is no Reply activity to be used as a notification -- you have the side effect without the activity.
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles re: the Undo Accept thing vs Reject thing, using a Reject is prone to issues with out-of-order deliveries. if you send a Follow and get back an Accept and a Reject with the same published datetime, then are you currently a follower? what if the Reject came first but then you receive a later Accept? it makes it incredibly hard to reason about the distributed state machine, and leads to terrible desyncs when one side thinks you follow them and the other doesn't.
-
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles re: the Undo Accept thing vs Reject thing, using a Reject is prone to issues with out-of-order deliveries. if you send a Follow and get back an Accept and a Reject with the same published datetime, then are you currently a follower? what if the Reject came first but then you receive a later Accept? it makes it incredibly hard to reason about the distributed state machine, and leads to terrible desyncs when one side thinks you follow them and the other doesn't.
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i think there needs to be a way to get a consistent event log in-order from the canonical/authoritative source. failing that, though, the least you could do is have your activities refer to each other in an obvious way. Undo(Accept(Follow)) lets you reverse-reconstruct what happened because all 3 activities are right there (hopefully fetchable!). so maybe Undo(Add) makes more sense than Remove; perhaps we say that the Remove is the result of the Undo?
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian@fietkau.social in a parallel conversation not about interaction controls, @rimu@piefed.social made the case for batching events, which I'm going to repurpose as an argument against sending additional activities for backward compatibility (unless absolutely necessary.)
> As a user can do a great number of notable things (posting content, liking content, following others) each minute and there can be thousands of instances to send to, a great many POST requests can be sent in a short amount of time.
>
> For example if 5 people cast 20 votes and there are 500 instances, the instance hosting the community containing the posts being voted on must send 5 * 20 * 500 = 50,000 HTTP POSTs.
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles this makes me really wish people didn't overload the AS2 vocab so much, and were less afraid of defining their own extensions. you could swing it so that the same activity is an Add, Accept, and ReplyAck. it sucks that we have to pick one instead of using whatever makes sense. (developers: please support multityping and/or duck typing! composability is the only true path to extensibility, and one size never fits all...)
-
@trwnh There's also this, yeah. GTS interaction controls have already gone through one breaking schema revision from version 0.19 to 0.21 (with 0.20 trying to manage both), and a core goal of the FEP I'm working on is to not break compatibility again.
Sending out an Add in addition to the Accept(Note) that's already happening should be non-breaking for existing implementations, I'm pretty sure. What's left to decide is whether it's a good idea.
-
@trwnh This is in the context of a FEP draft which prescribes a meaning (including desired side effects) for compliant implementations.
Hence my fidgeting with the vocabulary. The effects are the goal, the question is how they should be expressed and broadcasted. (Principle of least surprise, potential compatibility with existing implementations that look at the replies collection, concerns around server traffic...)
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles i think the issue here is that projects are doing things that may or may not get widely adopted, then if the proposals ever change, they have to deal with older software only understanding the old thing they tried. (this is where i would say something about protocol capability negotiation)
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles alternatively add the Reply itself, parallel to likes/shares collections. it depends on whether you think the replies collection should always contain a specific type of object, which i don't think is something you can guarantee because publishers can do anything with it. similar to how some publishers include activities in threads and some include notes.
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles
> replies collection is the source of truth for replies curated by the object owner.
this is fine i think, but the way to do this usually is HTTP GET. you could notify of changes to the replies collection, or you could reify the Reply and then Accept that?
the Reply has an instrument which is the Note. it has clear side effects to Add the instrument to the object.replies. the side effects can be gated behind Accept/Reject like following currently works.
-
@julian@fietkau.social @evan @julian@activitypub.space @smallcircles
> express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view
i get that, but the question is whether you can claim this understanding universally for all peers. as it stands, Accept is very vague wrt this. Accept(Note) meaning "Add to replies collection" might be a thing gts does, but that's their interpretation of Accept, not the definition.
