I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
59
Posts
9
Posters
33
Views
-
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?
-
@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?
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i guess you could hack it with inReplyTo on the Activity, if you assume responses always come after the thing they are responding to (although i could make a famous joke here about answering a question before it is asked).
-
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i guess you could hack it with inReplyTo on the Activity, if you assume responses always come after the thing they are responding to (although i could make a famous joke here about answering a question before it is asked).
@evan @julian@fietkau.social @julian@activitypub.space @smallcircles anyway, to address julian (not lam)'s question: what does Accept(Note) even mean? what does it entail? can you always assume it has to do something with a replies collection that may or may not be there?
-
@julian @deadsuperhero @evan POST outbox is the vision of C2S btw -- nodebb is a client in that regard, letting users publish activities of whatever they did on nodebb, to their activity stream.
i recently filed an issue on ap-api for "suggested activities" to improve the security issues with letting others POST to your outbox directly: https://github.com/swicg/activitypub-api/issues/53
-
@julian@activitypub.space @general@activitypub.space @evan@cosocial.ca Again, this is sort of why I'm advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you're saying with some kind of representation of a timeline. Even if it's just plain old algorithmic time-sort.
@deadsuperhero @general @julian @evan concept: attaching Applications to your inbox, each of which do their own thing. right now we have effectively monolithic apps that have exactly one "internal AP client" attached to the inbox.
-
> it seems a waste of resources to try to track it.
is it? did someone ask to receive updates of every single change? if not, then maybe. the level of detail is an open parameter here...
-
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.
> use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
i'm tracking inbox items and outbox items as separate from the activity content/payload. no source release yet but the idea is that inboxes receive "notifications" instead of "activities". notifications have their own timestamps so receiving a notification whose activity content claims to be in the future/past won't cause any confusion for readers.
-
#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 @evan @julian if only the application domain of activitystreams was activities and streams... ;)
i do think it causes a lot of confusion to stray away from activities as content, instead using them as vehicles for state changes (which will never be consistent, not even eventually consistent).
back when atompub and atom+as1 were a thing, the "feed entry" was atom semantics and the "activity stream" was as1 semantics. they coexisted in the same xml file. it worked well enough.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Removed Gmail from my bottom the screen links on my Pixel phone.
Facebook immediately jumps onto it's spot.
Me : "yeah not you, Facebook" and immediately drags Tusky into its position.
#fediverse #metasucks #metaistoxic #mastodonrocks #facebook #facebookistoxic
-
Bonjour ! @Neko0001
-
@francois6po
bonjour François
❤️😙❤️
-
@rperezrosario
Exclusively I have used the mobile App Tusky for +3 years.
-
@rperezrosario Mona app lets me set things up exactly the way I like them, so after trying the official app and my browser for a while, I now use Mona on the iPad, mostly. I haven’t set eyes mastiot in my phone. I don’t love it but I’m used to it.
-
@rperezrosario @phanpy ! (and @Tusky on mobile)
-
@rperezrosario IceCubes native app on macOS and iPadOS 26.x. I rarely/never check my feed on iOS.
-
@beeoproblem @rperezrosario this!
