#social 2019-09-25
2019-09-25 UTC
# 
fr33domlover trwnh, it's indeed very easy to turn any object into an actor. And it's a question I've asked before: Should anything be an actor whenever it's convenient, or is there some other guideline? And after much discussion, the guideline I picked is that individul objects with an independent meaning would be actors, and objects that only exist in the context of something else wouldn't be actors. Under that
# fr33domlover guideline, issues aren't actors in my implementation because they're tied to a project, and that project is an actor and it sends and receives all the activities related to the issues that are under it
Guest84 joined the channel
# trwnh fr33domlover: "whenever convenient"? activitypub is an openworld protocol so it's mostly "do what you want". i would suggest letting people Follow a Service that happens to Announce any Activities related to that issue. like a relay, basically. but there's nothing preventing you from having that Service at the same "id" as the object itself, and say having type:[Issue,Service]
# fr33domlover trwnh, yeah that's possible. But it raises a very big question I'd like to see clarified: In AP, should everything that can be followed be an actor? And whenever you want some OrderedCollection of activities to be possible to follow, should you create a new actor for it?
# fr33domlover It's fine if the answer is yes; but some people here have expressed an opinion that it's too fine grained and that being possible to follow doesn't necessarily mean the object should be an actor. Idk. Hmm maybe I'll write in the forum(s) about this
xmpp-social joined the channel
# 
jaywink[m] It seems perfectly fine that someone could "Follow
{ Note }" for example to get updates on it or Follow a Page, or anything that might receive updates in terms of follow-ups or edits.# jaywink[m] Making everything an actor seems wrong and would likely just create lots of profiles in various platforms that are not real profiles but actually just a random note that is also an actor
# jaywink[m] how the platform receiving a follow of a note handles sending the updates or tracking the updates is implementation detail, that isn't something that should be defined by activitypub?
# jaywink[m] thinking of other protocols, a Follow
{ Note } is pretty much what a Participation entity is in Diaspora protocol# fr33domlover jaywink[m], yeah I like to think of actors as islands that can send out stuff and receive stuff from other islands, and each such actor may be complex and have smaller objects it manages that aren't actors, and the actor may also manage the access rules to those smaller objects etc. It's a bit like a house with family members and the parents keep track of mail arriving for their children etc.
# fr33domlover In AS2 that works fine, but the AP spec implies that Follow is always done on an actor
# jaywink[m] hmm where is that?
# fr33domlover jaywink[m], in a few places in the spec, e.g. when it describes the follower/following collections and the Follow C2S and S2S activity side effects
# fr33domlover Anyway, for now I'm going with the follow-non-actors behavior
# fr33domlover I think I'll also add a custom propety that non-actor objects can use to specify the actor object that manages them
# fr33domlover So that it's easy to tell how to interact with such non-actor objects
# jaywink[m] yeah I think it would be bad to limit Follow to actors or make everything an Actor due to the vagueness of the spec. the mention of "Follow is used to subscribe to activities of another actor" in the C2S part seems very restrictive indeed, funny I didn't notice that before :/
# jaywink[m] probably never fully read the C2S part :D
# jaywink[m] > <@irc_fr33domlover:cybre.space> I think I'll also add a custom propety that non-actor objects can use to specify the actor object that manages them
# jaywink[m] isn't this https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attributedto or do I misunderstand?
# fr33domlover jaywink[m], attributedTo is who created the object. But it's possible e.g. I opened an issue on your project, but the issue is managed on your server by the project actor, or by you, definitely not by me
# fr33domlover I don't mind using a standard property but the standard ones that fit seem to have other uses that I already use, so, considering a custom property :p
# fr33domlover such as "managedBy" or whatever
# jaywink[m] hmmm not sure I understand what is planned in regards of issues in forgefed. the way I would see it is that things would be very vanilla AS2/ActivityPub. what purpose does it solve to know who manages an issue?
# trwnh But this may be desirable, depending on what level of interop you are aiming for. For example, following an issue from Mastodon, and unfollowing it once you no longer care. [01:42:41] <b94600jaywink[m]> Making everything an actor seems wrong and would likely just create lots of profiles in various platforms that are not real profiles but actually just a random note that is also an actor
# jaywink[m] I think Mastodon should in that case support following Note's, not the other way around of making all Issue's an Actor :) interop is good but all issues being an actor sounds like if forgefed becomes popular all mastodon instances would be mostly full of issues, not real users ;)
# jaywink[m] re for determining who can close an issue for example, the spec could just define that an issue can be closed by 1) the Actor who owns the Repository and 2) the actor who created the issue ?
# trwnh You could use "streams" on a managing actor, e.g. a Group or Person, but that would only work for impls that support viewing/subscribing to streams, and you would have to create new streams. Frankly, making a Service just sounds easier [01:19:14] <b94600fr33domlover> whenever you want some OrderedCollection of activities to be possible to follow, should you create a new actor for it?
# jaywink[m] the easiest path is not always the best ;)
# trwnh Yeah, which is why I think a Service acting as effectively a relay could work. In Mastodon terms it could be like a system actor that sends Announces bto: everyone who sent a Follow Object, then it's up to UI to make it work [02:08:52] <b94600jaywink[m]> I think Mastodon should in that case support following Note's, not the other way around of making all Issue's an Actor :) interop is good but all issues being an actor sounds like if forgefed becomes
# trwnh popular all mastodon instances would be mostly full of issues, not real users ;)
# trwnh kinda like interfacing with github issues over email
# trwnh essentially leaning into the "activitypub is email over json" thing
# trwnh it really seems though like websub had it easier lol
# jaywink[m] but github issues are not profiles
# jaywink[m] I think AP for issue management should not be modeled over compatibility with mastodon. Compatibility is good, but it shouldn't drive everything.
# jaywink[m] compatibility with other forges is more important and since forgefed is just being drafted - there are no design boundaries there driving decisions
includeals_, puck, stevenroose, dansup, Guest84, tenma, lain_soykaf, csarven, ben_thatmustbeme, KjetilK, Gargron and martijnvdven joined the channel
# trwnh honestly there's no guarantee an actor also has a profile, but no one really uses Profile as a type unto itself
# trwnh it's kinda just assumed
# trwnh and yeah for forgefed extensions are fine and expected. there should probably be a fallback though, just like email is a fallback
biodan joined the channel
# dansup fr33domlover: congrats 🎉 really awesome to see vervis evolve :D
# fr33domlover dansup, thanks :) I see PixelFed evolve all the time via your fediverse posts :)
Guest84 joined the channel
# rigelk[m] is there a way to advertise an alternative representation of an object via the Link header on a page? Usually clients retrieve an object with a `Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"` request header, but could we imagine an object Cast to allow compatibility with more limited implementations? They would send a request with the more specialized `Accept: application/ld+json;
# rigelk[m] profile="https://www.w3.org/ns/activitystreams#Note"` request header if the object first retrieved is not one supported, for instance. Would it make sense?
# nightpool[m] not sure I follow
# nightpool[m] the same URI would have two different ActivityPub objects?
# nightpool[m] so depending on how you retrieved it, or who you retrieved it from, the object with the same id could be completely contradictory? that seems bad
# rigelk[m] no, but one would cast to a basic Note
# rigelk[m] probably. I figured it could help new object types at least get a basic display as a Note in mainstream implementations without having them to modify their codebase.
BitBot, dmitriz, ilmu and ma1uta joined the channel