mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

380K
active users

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

@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)

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!

@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.)

@trwnh @evan uh woops. s/attributed/audience:d/; or probably should be "if the Update activity is not visible to you", actually

(yes, Kroeg has Update support but our frontend UI ..doesn't.)

@trwnh @evan This is true. Unfortunately people demand the right for things to be forgotten (which of course they never really are).

@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.