i really wish fedi software was more focused on web publishing, yknow, publishing resources to the world wide web
and you could separately manage communities and have discussions
and you could also separately message people or chat rooms
and you could separately read/consume all of these disparate forms of communication instead of having them collapsed into the same thing (to poor effect)
@trwnh so, how do you feel about using a single account for all those activities? Even if they are different apps (Web or native)?
@evan i don’t think the concept of an “account” makes sense per se. at a ux level sure, it makes sense, but at a protocol level i think we need clearer separation between building blocks like identity, data storage, transport/pubsub, and so on.
the main thing though is i’m not really convinced that the activity model is a good fit for everything. i’m intellectually uncomfy with how activities are notification resources *and* often also procedure calls. how fedi uses ap feels a bit disjoint imo.
@evan this is more of a critique of “fedi as social media” than it is “ap as protocol” but it is a bit weird that we have what is effectively a global database with no consistency mechanisms built into it, conventionally speaking
@trwnh I'm not sure that is true. The up to date definitive version of every object is an HTTP GET away.
@evan cache invalidation is a Hard Problem though!
@trwnh in theory, yes. In practice, most objects stabilize pretty quickly -- hours or days.
@evan this is often not true for Collections though. there's already more than one FEP about trying to detect when collections drift out of sync. and looking outside of AP, Matrix as a protocol was founded on the idea that that syncing repos of data was their primary problem to solve, not messaging or chat
@trwnh we have `updated` for that.
@evan do you then fetch the entire Collection and page through the whole thing, though? this is inefficient. one of the advantages of an event source model is that you can get pushed updates when something changes... but if you miss an event then you're out of sync. so you need a way to get back in sync, preferably without having to fetch/page the whole thing every time some digest or timestamp changes.
@trwnh again, in theory, that sucks, but in practice, only the most recent pages are updated frequently.
@trwnh and once you find the updated page, you don't have to keep synching.
@evan this assumes append-only with none of the old pages changing
@trwnh yes, which is a correct assumption. Removals from a collection are way less common than adds, for most collections.
@trwnh for collections that aren't reverse chron, it's indeed harder but conversely those are kind of uncommon. On purpose!
@evan removals aren't *uncommon* though, and each removal shifts the index of every item. reverse chron doesn't solve this. actually it makes it worse! you need forward chron append-only -- this is the only way to ensure old pages stay consistent. your collection basically becomes a changelog. one downside is that removed items leave behind a record that they once were included. you get this issue with any append-only structure unless you rewrite history (making it no longer append only)
@evan what we have in current fedi is... not that. rewriting history is more common than you'd think. mastodon does it for edited posts, for example -- the outbox doesn't include the Update, it actually goes back and regenerates the Create with the edited object!
@trwnh @evan I think this is a mischaracterisation of the actual/supported behavior? the Create
activity still refers to the object
's ID, which, in its inline representation, is updated. The lack of Update
in the outbox
is entirely fine; even if the Update
activity is not attributed to you, the update is processed, as its behavior entirely hinges on the C2S api. (Though, my interpretation of this behavior is from a relatively unconventional JSON-LD point of view, in the way that Kroeg uses it.)
@khleedril things can be forgotten, it's more of a technical decision on whether to persist in history or not to do so. you needn't keep a record of everything in perpetuity.
@trwnh if your pages are like "first twenty items" or "start index plus 50 items", yes. That is the worst way to do paging. Removing an item from one page should not affect other pages. Treating pages like first class objects fixes most of these problems.
@erincandescent @trwnh I like keeping it simple: a collection is a doubly linked list of pages, and a page is an array of items. Add items to the first page until it's at some max size, and then insert a new page at the front. Easy peazy lemon squeezy.
@erincandescent @trwnh Anyway, I think we got way off your original point, a, which is that ActivityPub is really good for Web publishing. I disagree with your thoughts about other uses -- I especially like social games, but there's a whole chapter of my book on future applications -- but I agree that the CRUD cycle is handled pretty well.
@evan @erincandescent i may have not worded myself precisely enough but i am not against other uses; what i am uneasy with is the collapse of every paradigm of communication into a one-size-fits-all application of protocols. like, it would be better to have some consistent identity layer that could be used to not only publish streams of activities, but also to do proper messaging with a predefined audience to which people can be added and removed, and also to join and participate in communities.
@evan @erincandescent basically i really like the idea of publishing an "activity stream" on my website, or publishing notes and articles and pages and so on via some activitypub-powered CMS that then generates a website. mastodon et al could also do more to focus on "microblogging" than it currently does to reproduce the platform experience. i'm not fully done exploring the ergonomics and boundaries of all this, though!
@evan maybe the worst way but also the most useful! although i did explore statically generated pages back in 2022 (see https://socialhub.activitypub.rocks/t/stricter-specifications-for-pagination-of-collections-and-orderedcollections/2633 for that), i find that broadly speaking Collection paging benefits from being treated as a dynamic presentation layer. as a consumer, you often want the examples you cited. nevertheless it should still be possible to do static paging or ahead-of-time optimizations, as in the socialhub thread.