I wish #ActivityPub was a "pull" protocol instead of a "push" protocol.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog it would be very mixed. Posting in self hosting be more trivial, but loading a feed would require querrying hundreds or thousands of servers.
Particularly when thinking of all the dead/inactive accounts that would need to be queried...
And those queries would be a bit expensive.
It would also radically reduce the reach of public posts, they'd only be visible on other servers after a follower had refreshed their feed, this would break public feeds
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog
entirely agree with that.
that is how dat works by design, and it has an option to opt into or opt out of push too. -
@soapdog it would be very mixed. Posting in self hosting be more trivial, but loading a feed would require querrying hundreds or thousands of servers.
Particularly when thinking of all the dead/inactive accounts that would need to be queried...
And those queries would be a bit expensive.
It would also radically reduce the reach of public posts, they'd only be visible on other servers after a follower had refreshed their feed, this would break public feeds
@LovesTha it would be a radically different experience indeed. The key is when to fetch, right? You can’t fetch as you build the feed for visualisation, fetching is slow.
You need to either make it an explicit action such as a refresh button or fetch in the background according to some interval.
Regardless, you would cache it and the feed always shows the cache. It might be out of date but it is local and fast.
Marking broken and inactive accounts is easy.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog Yes, lots of details to work out for our use cases, but the pull model is what makes RSS so crazy powerful and scalable. Push models are resource hogs that approach exponential growth in a large network like the fediverse — the medium-sized site that hosts my account is constantly struggling to stay one step ahead of the fedi's surging resource demands.
-
@soapdog Yes, lots of details to work out for our use cases, but the pull model is what makes RSS so crazy powerful and scalable. Push models are resource hogs that approach exponential growth in a large network like the fediverse — the medium-sized site that hosts my account is constantly struggling to stay one step ahead of the fedi's surging resource demands.
@david_megginson that is the exact problem that I want to get rid of. It really sucks. For example, I'd like to host a single-user AP server here at my flat, but knowing that it will use so much bandwidth is enough for me to reconsider it.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog Why would it make it easier to self-host? Dealing with pull requests is on the whole more difficult than a simple send-and-forget. Tracking who is in on a conversation is easy enough. On the other hand, tracking every conversation you've ever been in is way more difficult, and wasteful pulling from every single one of them. It wouldn't work.
-
@david_megginson that is the exact problem that I want to get rid of. It really sucks. For example, I'd like to host a single-user AP server here at my flat, but knowing that it will use so much bandwidth is enough for me to reconsider it.
@soapdog Part of the problem is that we set the expectation that the fedi would work just like a monolithic social media site. If we reduced that expectation just a little, the demands would go down a lot.
Users already accept (or fail to notice) that Mastodon's search and hashtag features aren't really global across the fedi.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.
-
@soapdog There's a poll-based version specced at https://fediverse.codeberg.page/fep/fep/b06c/, sadly with no notable implementations (wouldn't be interactable by Mastodon etc.), but it's an opportunity to break new ground as an implementer if you know anyone who'd like to experiment with it.
@julian that was a very interesting read. I think I can implement this. Will try a small experiement soon. Thanks for sharing.
-
@soapdog Part of the problem is that we set the expectation that the fedi would work just like a monolithic social media site. If we reduced that expectation just a little, the demands would go down a lot.
Users already accept (or fail to notice) that Mastodon's search and hashtag features aren't really global across the fedi.
@david_megginson the good thing about expectations is that we can adjust them :)
I'm not saying replace AP with something else, I'm saying let's build something different and let them all blossom. I really liked the spec described here:
-
@julian that was a very interesting read. I think I can implement this. Will try a small experiement soon. Thanks for sharing.
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
We're using pull semantics for data exchange in the federation of wikis, if you'd like to try that out. #FedWiki
via @smallcircles
-
-
@evan @soapdog True. I was talking about this just yesterday, if we wouldn't be better served by something wiki-like to host a software project × FEP implementation matrix instead of asking FEP authors to keep their lists updated.
That aside, in this context I'm thinking about how more implementations in the wild can motivate other implementers. My own website still isn't AP-capable (it's planned, but low priority). If I knew there were a sizable ActivityPoll user base, I'd more likely use it.
-
@evan @soapdog True. I was talking about this just yesterday, if we wouldn't be better served by something wiki-like to host a software project × FEP implementation matrix instead of asking FEP authors to keep their lists updated.
That aside, in this context I'm thinking about how more implementations in the wild can motivate other implementers. My own website still isn't AP-capable (it's planned, but low priority). If I knew there were a sizable ActivityPoll user base, I'd more likely use it.
-
undefined hongminhee@hollo.social shared this topic
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog makes sense. I never had fear of not being able to selfhost an RSS feed
-
System moved this topic from General Discussion
-
I wish #ActivityPub was a "pull" protocol instead of a "push" protocol. The way it works, whenever you take an action, it sends that action to all followers. I would prefer if it simply stored them and then let each follower pull them when they see fit.
That would introduce latency and more async comms as your messages wouldn't pop up into someone elses feed until their software fetch the data, but I think it would make it easier to self host.
@soapdog@toot.cafe hmm... just thinking aloud here.
You posit in another post that the network effects inflate exponentially:
> Push models are resource hogs that approach exponential growth in a large network like the fediverse
That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.
If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!
Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.
If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666
i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).
-
-
@reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?
Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0
-
With ActivityPub / ActivityStreams...
To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.
That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.
I'll just call this common parent: 'Entity'.
...
It could have even been an opportunity to talk about how to handle unknown types.
-
@soapdog@toot.cafe hmm... just thinking aloud here.
You posit in another post that the network effects inflate exponentially:
> Push models are resource hogs that approach exponential growth in a large network like the fediverse
That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.
If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!
Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.
If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.
-
@evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.
-
@evan my suggestion: https://github.com/w3c/activitypub/issues/533
-
@evan @mariusor @silverpill re: ids though the RDF ecosystem (and jsonld) doesn't use "null", it uses blank node identifiers (those prefixed with _: are special cased by the prefix expansion algorithm). this can allow for "transient" activities or "anonymous" objects (and the graph data model auto assigns _:b1, _:b2 and so on when "id" is missing; the canonicalization algorithm assigns _:c14n0 and _:c14n1 and so on)
this is maybe not the best way to create replies collections though...
