#social 2019-04-01
2019-04-01 UTC
vitalyster, naturzukunft, xmpp-social and rZr joined the channel
# 
rZr hi, may the url of the forum be added on wikipage or at least this irc topic bar ?
# dansup what forum?
# rZr it took me some times to find the url back
# dansup That is an unofficial forum of AP, it doesn't need to be added
# cjslep[m] RzR I feel your pain, I have a massive bookmark collection in my browser for all AP related things.
# rZr so we could link all on wikipedia ;)
# rZr doesn't use bookmark anymore
ichoquo0Aigh9ie, Guest84, timbl, ahihi, xmpp-social and timbl_ joined the channel
# fr33domlover o/
# fr33domlover Are collections generally cached? e.g. is it possible / do servers cache follower collections of remote users?
# fr33domlover It sounds like a problem because if you cache, there's no way to get updates on changes in the collection
# fr33domlover (Hmmm or is there? And if there is, I wonder if it's really better than just fetching every time without caching)
Guest84_ and timbl joined the channel
# cjslep[m] Servers don't generally specify every follower when federating. They just point to the collection and let the receiving server actually do the most up to date delivery
# fr33domlover cjslep[m], hmm what do you mean point to the collection? If I, server A, need to deliver some activity to some collection on server B, how do I do that? If I understand correctly what jdormit[m] said earlier, I fetch the collection, and deliver to the inbox of each actor in the collection
# fr33domlover Hmm but I guess it could pick 1 follower, deliver only to them, and the target server will do inbox forwarding to all the other followers?
# rialtate[m] You send to the attributeTo author of the collection, they deliver
# fr33domlover rialtate[m], I assume, given that the collection has one, and that it happens to be an actor? (And perhaps assuming that it doesn't change, so that it can be cached?)
timbl joined the channel
# fr33domlover Ah, I just realized, most servers do only S2S
# fr33domlover So they have full control over which collections are addressed
# fr33domlover If you implement C2S too, then there's no guarantee, a collection may have nothing but a list of actors, no attributedTo etc.
timbl and dlongley joined the channel
# cjslep[m] fr33domlover You just address the followers collection and the owning server will do inbox forwarding to figure out the specific actors in that collection.
# cjslep[m] C2S: Activity A addressed to person B and B followers
# cjslep[m] S2S A: send to S2S person B
# cjslep[m] S2S B: inbox forwarding to send to B followers whatever is in that collection
timbl joined the channel
# fr33domlover cjslep[m], but that works only for the followers collection; some collections aren't the standard AP ones. I suppose in general due to inbox forwarding it's enough to send an activity just once to each host on which we address at least one collection? Like, even if it's not the owner of the collection, it could be something from attributedTo? Or context, or tag, or whatever?
Luke_ and ahihi2 joined the channel
# cjslep[m] To make it most ActivityPub-compatible, at least one of the "to" addressees should be an actor owned by the server. This would be a point in favor of making things like projects or tickets fit into the Actor concept.
# cjslep[m] Because an Activity can only be delivered S2S to an inbox on a peer's server. So only addressing it to a group of collections is a problem not specified in the existing ActivityPub definition.
# cjslep[m] A solution could be, for example, having a singleton actor Application representing an instance, but then you're creating a new "ActivityPub profile" unlike the existing ones
ahihi2 joined the channel
# fr33domlover cjslep[m], yeah I already have projects being actors, just wondering about the possibility of the case that for some reason you don't want to put the project in the "to". Right now I'm using that for display (if you target the project, then GETing the ticket will show you the new comment made, and otherwise it won't, so it will be a private comment). But hmmm maybe I could always target the project, and
# fr33domlover use the presence of "Public" to decide whether or not to display the comment?
# fr33domlover For now I suppose I could do the following in C2S: If the client sends an activity in which there's a remote collection addressed, and there's no actor addressed to the same server, then the server rejects the client's activity
# fr33domlover cjslep[m], I'm wondering about the 3rd condition for inbox forwarding: What if there's no inReply/object/target/tag in the activity sent? I still want the target server to deliver to collections it owns, but will it do that if none of those properties are specified? (or they don't have URIs owned by the server?)
timbl joined the channel
# fr33domlover If I send a comment via server A, replying to a comment hosted at server B, and these comments are about a ticket hosted on server C, then (1) there's no tag, no target and object is hosted at server A, not C, because it's my new Create Note; (2) inReplyTo has a URI of a comment on server B, not C; so, when server C gets my Create Note, will it do inbox forwarding to - ah wait, maybe I got confused. Maybe
# fr33domlover the spec means you recurse through inReplyTo, and if you find anything there hosted by you, then you do inbox forwarding? If that's the case I guess I'm ok because the top-level comment always has inReplyTo the ticket, which is owned locally
ahihi2 joined the channel
# cjslep[m] Yes, it is recursively looked up the tree so all participants involved continue forwarding child derivative discussions
jdormit and ben_thatmustbeme joined the channel
# fr33domlover cjslep, continue forwarding? How does that work? iiuc it's the client's job to address all participants? (when servers do inbox forwarding they don't add new recipients, just deliver if they see a locally owned collection?)
# cjslep[m] fr33domlover (IRC): Yes the client adds all participants. The client's server addresses it to those it can. The client's server's peering server uses inbox forwarding. Think of inbox forwarding as "being on the hook". Once a remote peer (the "other side" of S2S) has something it owns in the "tag", "object", ... etc properties that trigger inbox forwarding, that remote peer is "on the hook" to continuously check all child activities *of that first one*
# cjslep[m] to see if those activities were addressed to a collection it owns.
# cjslep[m] Since this is the client of C2S recruiting resources of a remote S2S peer, there's two guards that are in place to prevent abuse:
# cjslep[m] A) The spec allows limiting recursion (so only child activities of a certain depth are considered)
# cjslep[m] B) The spec allows the remote S2S peer to filter collections as necessary
# cjslep[m] sent a long message: cjslep[m]_2019-04-01_19:11:50.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/CnhaqayayhIyjieFTGhUTAgo>
timbl joined the channel
# fr33domlover cjslep[m], thanks for explaining :) what sort of filtering would be useful in B?
# cjslep[m] A general rule of thumb is if an Activity is addressed "to" or "cc" an Actor, then only collections associated with that Actor should be candidate recipients for inbox forwarding.
# cjslep[m] It won't stop Fediverse spam, but makes it more explicit that spam is occurring (more likely to be reported by B's users instead of requiring admins of B's peers to introspect the Activity data)
# fr33domlover cjslep[m], thanks! You've given me so much advice lately, thank you so much! May I ask, how do you know all these details? I don't wish to waste anyone's time, I just don't know sources for getting such info (other than digging in source code of various servers, but it's been really difficult to really figure out these details from there)
# fr33domlover That's why I often ask here in #social
timbl joined the channel
# cjslep[m] Probably two things: I implemented go-fed/activity, which is an ActivityPub library. Building a library instead of an application forced me to think about carefully dividing the protocol from an arbitrary application, and how to "scale" to any specific client application, and the consequences of such careful choices.
# cjslep[m] Second: I like to read as much and talk to as many fedi folks as possible. But not all of them. So I get exposed to a lot of different ideas, even if I personally don't agree.
# cjslep[m] Correction: I like to talk to all of them. But that doesn't mean I actually get the opportunity to talk to all of them
timbl and glothit7ok[m] joined the channel; vitalyster left the channel
# rialtate[m] It means that you are not getting a feed in return from them. The most common cause being that they haven't reciprocated your connection request but it can also mean they severed a previous connection.
# rialtate[m] Wrong tab
timbl joined the channel
# nightpool[m] fr33domlover (IRC): i think the other answer, especially for stuff like this is "there's no right answer"
# nightpool[m] it's okay to make a judgement call