[lorean_victor]

the system doesn't need to be completely pull-based though. I don't even think most modern RSS readers are fully pull-based, don't they support WebSub?

the main point is to separate publishing and distribution, making publishing far more accessible and decentralised. for that to happen, I guess, from a publisher's point of view, the system should be pull based. of course we can have hubs and relays to add pull-based mechanisms to ease the load of the system.

p.s. even in that case, strictly speaking, yes a pull-based system, or even a hybrid one, will always require more work than a fully push-based system.

[lxgr]

> the main point is to separate publishing and distribution, making publishing far more accessible and decentralised. for that to happen, I guess, from a publisher's point of view, the system should be pull based.

Oh, I completely agree with that assertion: Static content hosting is much easier than stateful subscription management, knowing which aggregators to post to etc.

I just think that this does inherently put more work on the subscribers, and there's no real way to do it efficiently in a relatively flat architecture (with subscribers directly polling publishers). WebSub helps with pure distribution, but not with aggregation (e.g. to allow keyword/hashtag search), for example.

That doesn't mean it's not worth still designing a system like that (in my view, the benefits are significant!), but I wouldn't call it a performance win.

[lorean_victor]

agreed. it won't be a performance gain at all.

but I suspect aggregating / indexing / etc. still is going to be the most resource consuming part of a push-based system if you want your content discovery to not be limited to two-way interactions, which means the gains of a push-based system, in terms of performance, shouldn't be that much (I suspect the main gains will be in realtimeyness instead).