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.
