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:

373K
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

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

@evan or in other words, for people, it should be more like email

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

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

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

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

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

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

@trwnh @khleedril Maybe the other way around. We already use `attributedTo` for authorship; add an `objectOf` for the `Create` activity.