infinite love ⴳ
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
@trwnh so, how do you feel about using a single account for all those activities? Even if they are different apps (Web or native)?
Matthias Pfefferle
@trwnh that’s exactly why I tried to bring WordPress into the fediverse!
infinite love ⴳ
@pfefferle this isnt agajnst 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
infinite love ⴳ
@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
Evan Prodromou
@trwnh I'm not sure that is true. The up to date definitive version of every object is an HTTP GET away.
infinite love ⴳ
@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 Prodromou
@trwnh no, the whole point is connecting people.
infinite love ⴳ
@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 ⴳ
@evan cache invalidation is a Hard Problem though!
Evan Prodromou
@trwnh in theory, yes. In practice, most objects stabilize pretty quickly -- hours or days.
Evan Prodromou
@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 ⴳ
@evan or in other words, for people, it should be more like email
infinite love ⴳ
@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
@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
@trwnh we have `updated` for that.
infinite love ⴳ
@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
infinite love ⴳ
@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
@trwnh again, in theory, that sucks, but in practice, only the most recent pages are updated frequently.
Evan Prodromou
@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.
infinite love ⴳ
@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.
Evan Prodromou
@trwnh and once you find the updated page, you don't have to keep synching.
infinite love ⴳ
@evan this assumes append-only with none of the old pages changing
Evan Prodromou
@trwnh yes, which is a correct assumption. Removals from a collection are way less common than adds, for most collections.
Evan Prodromou
@trwnh for collections that aren't reverse chron, it's indeed harder but conversely those are kind of uncommon. On purpose!
infinite love ⴳ
@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 Prodromou
@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
@trwnh booooo
infinite love ⴳ
@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!
Evan Prodromou
@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.
Erin 💽✨
@evan @trwnh they don’t even need to be reified, they can be purely computed. But they need to be computed off of a stable monotonically incrementing identifier
Which I think is how Mastodon pages work today
Evan Prodromou
@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 ⴳ
@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
@trwnh @khleedril Maybe the other way around. We already use `attributedTo` for authorship; add an `objectOf` for the `Create` activity.
infinite love ⴳ
@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 ⴳ
@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.
Khleedril
@trwnh @evan Totally agree. The /create/ wrapper around any object is technically redundant anyway, as all the information, including creation date and attribution, is in the object itself.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.