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
@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.
@trwnh no, the whole point is connecting people.
@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.
@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.