infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Sa 27.07.2024 22:46:38
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)
Evan Prodromou (@evan@cosocial.ca)
Föderation EN Sa 27.07.2024 22:56:01
@trwnh so, how do you feel about using a single account for all those activities? Even if they are different apps (Web or native)?
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 16:45:40
@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.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 16:47:02
@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
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 16:49:20
@evan i guess what i’m getting at is that the most sensible use of activitypub in my mind is as a backbone for peering web cms kinda things. in other words the primary actor model should focus on services not people.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 16:52:47
@evan or in other words, for people, it should be more like email
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 17:59:33
@trwnh I can kind of get behind this. But I think that means you should have one inbox per social role (personal, work, student, ...) rather than one per application (microblogging, long form text, games, images, video, podcasts, ...)
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 18:08:23
@evan that would be an improvement, but what would be an even bigger improvement is being able to publish and manage multiple collections, not just a singular outbox. it's a shame that the `streams` property hasn't seen implementation or usage! the other side of this is that i think that the Add should be more widely federated than the Create. Create is ironically described as having basically close to zero side effects in the AP spec, but in fedi it is the primary activity.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 18:11:32
@evan an example would be Google+ Collections, blog categories, or really any arbitrary collection of stuff
Create makes sense as a way to register that an object has been "created" in some kind of CMS or database. something like Neocities has an "activity stream" where you could easily map "x created a page" or "x updated a page" to activities. the activity is basically the "post", not the object.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Mo 29.07.2024 11:23:50
@khleedril @evan this is just convention. you could just as easily deal with Create activities in a way that isn't redundant. in that sense, the focus is less on the object itself and more on the act of creation. but it could go either way.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Mo 29.07.2024 11:24:56
@khleedril @evan one thing i was toying around with mentally, is if objects were attributedTo the Create activity that created them, and then having a separate property for authorship metadata. another way of doing it would be having some kind of object history collection, for activities where the `object` is the current object. then get the oldest/first item from that collection, which should be the Create (but that's less direct).
Evan Prodromou (@evan@cosocial.ca)
Föderation EN Mo 29.07.2024 14:06:38
@trwnh @khleedril Maybe the other way around. We already use `attributedTo` for authorship; add an `objectOf` for the `Create` activity.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 18:32:31
@trwnh I agree. I also think `streams` is helpful for sorting main timeline stuff (`Create`, `Announce`, `Question`) in the `inbox` from notifications like `Update`, `Like`, or `Add`. Also for list inboxes, direct messages, etc.
That all said, I think the right way to do things now is just add an extension property to the actor.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 17:52:29
@trwnh no, the whole point is connecting people.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 17:56:55
@evan people rarely want to be updated about *everything* an event source does. machines often do. this becomes apparent when you consider that certain activities are "internal" and not intended for consumption by people -- they're intended for machines to do something. this is the part that's weird to me. it feels like a lot of overhead.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 18:01:01
@trwnh could you give an example? A lot of the mechanics of AP, such as likes, shares, comments, follows, are things that people really enjoy getting notifications for.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 17:51:53
@trwnh I'm not sure that is true. The up to date definitive version of every object is an HTTP GET away.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 17:52:55
@evan cache invalidation is a Hard Problem though!
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 17:53:54
@trwnh in theory, yes. In practice, most objects stabilize pretty quickly -- hours or days.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 18:01:47
@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
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 18:08:23
@trwnh we have `updated` for that.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 18:14:42
@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.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 18:26:47
@trwnh again, in theory, that sucks, but in practice, only the most recent pages are updated frequently.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 21:24:33
@trwnh and once you find the updated page, you don't have to keep synching.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 21:25:52
@evan this assumes append-only with none of the old pages changing
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 21:35:13
@trwnh yes, which is a correct assumption. Removals from a collection are way less common than adds, for most collections.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN So 28.07.2024 21:36:13
@trwnh for collections that aren't reverse chron, it's indeed harder but conversely those are kind of uncommon. On purpose!
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 23:38:07
@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)
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 23:41:18
@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!
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Mo 29.07.2024 11:29:09
@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.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN Mo 29.07.2024 00:07:10
@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.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN Mo 29.07.2024 02:18:44
@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.
Evan Prodromou (@evan@cosocial.ca)
Föderation EN Mo 29.07.2024 02:26:42
@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.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Mo 29.07.2024 08:28:05
@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.
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN Mo 29.07.2024 08:23:13
@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.
Matthias Pfefferle (@pfefferle@mastodon.social)
Föderation EN Sa 27.07.2024 23:02:59
@trwnh that’s exactly why I tried to bring WordPress into the fediverse!
infinite love ⴳ (@trwnh@mastodon.social)
Föderation EN So 28.07.2024 16:35:28
@pfefferle this isnt against wordpress, but the concept of publishing into the fediverse is kind of flawed at present, and imo it comes down to a few things:
- as2 being better fit for an “activity stream” or stream of activities than it is for publishing resources
- mastodon et al being inspired by social media and aiming more for replication of “posts” across “instances” rather than for publishing
- current paradigms treating the fediverse as a discrete network instead of as the web itself
