#social 2019-06-23
2019-06-23 UTC
# 
up201705417 fr33domlover: but maybe it wouldn't be a terrible idea something like 'alternativeActorWebfinger'? If it fails to deliver in something like a day, mention this other actor instead.
# rialtate[m] Sounds a lot like zot `locations`
xmpp-social, Guest84 and cwebber2 joined the channel
# fr33domlover Is there in AP a property that is the reverse of "result"?
# fr33domlover E.g. if an Accept activity has "result" pointing to some object that got created as a result of accepting some offer, how do I point from that object to the Accept activity?
# fr33domlover something like "isResultOf"
# fr33domlover I think I can do without this property but wondering which property I'd use for this :)
# cjslep[m] Why would "Create" not be a good Activity reflecting the creation of a new object?
# rialtate[m] > <@irc_fr33domlover:cybre.space> I think I can do without this property but wondering which property I'd use for this :)
# rialtate[m] fr33domlover: origin
# fr33domlover rialtate[m], origin's domain is Activity. cjslep[m], that's a separate question, and I'm actually curious what you and rialtate[m] and others think: If an actor receives an Offer and sends an Accept, should a Create activity be sent automatically as well? Use case: A person wants to open an issue on a repo, the person sends Offer
{Ticket} to an actor of type Project, and the Project automatically sends an# fr33domlover Accept and creates a new issue (and notifies the humans who work on the Project), should the Project actor also publish a Create in addition to the Accept?
# fr33domlover Content-wise it causes some duplication (the entire original issue is already found in the Offer, and the Accept's "result" links to the newly created issue)
# cjslep[m] That sounds like a good way to handle it, yes.
# fr33domlover But otherwise is there some use for that Create?
# fr33domlover I mean, we could say the Project actor Creates a new ticket following the Accepting of the Offer
# fr33domlover So it makes sense to send that Create
# cjslep[m] Yes. Existing implementations already handle "Create" pretty easily. Makes it easier for others to support your use cade
# fr33domlover But also, just having Accept's "result" link to the new issue is kind of enough
# fr33domlover cjslep[m], yeah but it would be a Create of a non-standard object anyway + there's a slightly misleading bit maybe where the Create is attributed to the Project but the actual content isn't original, it was authored by whoever sent the Offer. And if a server requires Create's actor and object's attributedTo to match, it would reject such a Create where they're different
# fr33domlover cjslep[m], that's my argument againt the Create and that's why I'm unsure and hoping to hear feedback and decide together with community ^_^
# fr33domlover )I mean, there's arguments for and arguments against, and I'm unsure)
# rialtate[m] fr33domlover sounds like you are recreating SOAPYAPE but in a completely incompatible way
# fr33domlover rialtate[m], what I'm doing is standard AP ^_^
# fr33domlover Not creating anything new here
# fr33domlover Offer and Accept etc.
# rialtate[m] Disingenuous
# fr33domlover rialtate[m], the automatic Create would sort of be the awkward part, I agree, that's why I'm hesitant. But Accept and Offer usage here is standard
# rialtate[m] It's just that SOAPYAPE was carefully developed by 5 researchers over 9 months and specifically handles that Create aspect
# rialtate[m] Its also compatible with Zot and other protocols
# fr33domlover rialtate, I'll read your soapyape comment on SocialHub and reconsider things. But side note, once the Lice proposal thing in Litepub gets finalized, it's very possible I'll use it, and probably Pleroma and PixelFed will
# nightpool[m] @rialtate:matrix.org: considering that the only result I can find when googling this "SOAPYAPE" thing is one off handed forum post, it seems unlikely it enjoys broad implementor support
# fr33domlover rialtate, I read it again. It's very complicated and heavy for my simple trivial use case. The only reason I'd use it, is if the fediverse did, otherwise a much simpler thing (such as Lice or Offer/Accept) is enough for me and way easier
# rialtate[m] fr33domlover It is literally the same as what you said but instead of an ambiguous Offer it has an unambiguous Create
# rialtate[m] I can't find Lice
# rialtate[m] nightpool: I don't know why you expected different. AP has only existed 2 years. That's a strawman concern.
# rialtate[m] And it's just a "remote" version of C2S for servers that also act as the client. It couldn't possibly be simpler, and has 3 less steps than the Offer/Accept actually so I don't even understand why you think it's complicated.
# fr33domlover rialtate[m], I want to know how you counted the steps exactly ^_^ Btw lice is on the litepub website somewhere, that website is indeed not in the best shape right now, I hope its creators will improve it. The Offer/Accept thing isn't C2S, it works via S2S and it's very simple: You send an Offer, recipient hopefully sends an Accept or a Reject. That's all. And I'm not sure it's as ambiguous as you think;
# fr33domlover at least I want to give it a test drive and see how that goes. Btw I'd love to see the soapyape spec, it would be easier to talk about and understand
# melody it seems like creating remote objects directly kind of assumes the remote server wants to give you permission to create objects -- even with the oauth situation allowing the remote server to create on behalf of the user, if there's any opportunity for the remote server to step in and potentially prevent that create (which there should be) the flow would end up needing to resemble the same handshake as offer/accept/reject
# cjslep[m] That's why I've been repeatedly suggesting C2S and S2S combined for this use case. Even if the C in C2S is another server. But no one really seems interested.
# rialtate[m] I think everyone is talking through each other
# fr33domlover cjslep[m], I'd love to hear your suggestion. By the way, I kind of like the idea that when you send stuff to be stored/done remotely, it's an Offer and not a Create, even if you have an auth token. Because you don't have control over the other server, there's always a chance it just surprisingly refuses your object, it's a remote server and you can't just INSERT into its database. So Offer is kind of like
# fr33domlover "I expect you to store this, but no matter what I do, it's up to you, please send me back an Accept with the ID of the new thing, to let me know you indeed created stuff on your side"
# fr33domlover Create is kind of implicit because when the client sends a Create, the server makes sure to publish the object
# fr33domlover But when it's not your home server, that guarantee doesn't exist, there's this one extra step of being sure the object did get created, and I like the conceptual aspect of using Offer/Accept for this
# fr33domlover Just a semi philosophical side note ^_^
# rialtate[m] Again, soapyape handles that, but whatever
# melody yeah, across instance boundaries you just can't trust that the remote server wants your objects, is the thing, acting as a client doesn't help that scenario, the remote server never gets a chance to decide if it wants you as a user with thoes permissions
# cjslep[m] That's exactly what a C2S Create is, like any other REST call to create, like this Offer/Accept flow you have.
# cjslep[m] melody same thing could be said of S2S federation. Only difference is C2S has different semantics (side effects) for the Activity vocabulary.
# fr33domlover Well, the way I currently do this is: If you want to publish on your homeserver, you C2S a Create. If you want to send something for usage of a different server, you C2S an Offer, and then your homeserver and the other server netogiate the Offer/Accept/Reject
# melody S2S the server actually has a lot more leeway in spec to reject activities
# fr33domlover *negotiate
# rialtate[m] Yeah,, fwiw its worth, sending a 200 and not doing the INSERT is no different than sending an Accept and not doing the insert
# cjslep[m] I look at this problem from a very general perspective... Is every problem ever where server A wants to trigger some custom behavior of B going to go through this narrow Offer/Accept flow
# fr33domlover rialtate[m], you can't get away with not doing the insert that easily, if the Accept is expected to specfify a "result" field which others can then dereference
# cjslep[m] Or are we going to establish on an already derived and expressive solution like C2S
# rialtate[m] fr33domlover: not easy to make up a fake valid url? Weak argument
# cjslep[m] I'm not going to be inclined to have go-fed support the Offer/Accept flow out of the box
# cjslep[m] And go-fed's apcore is likely going to use C2S out of the box to solve this general problem
# cjslep[m] I don't want Offer/Accept narrowly defining all side effect behavior. I would rather just Create
{ <behavior> }# cjslep[m] That's my take on the general problem
# fr33domlover cjslep[m], mixing C2S and S2S sounds like something that breaks the actor model, imho imagine a p2p situation where there's no C2S, there's just 1-user instancs and all they do is S2S
# fr33domlover and then what's the difference between a "please create this" Create and a "this was created a few minutes ago" Create
# fr33domlover I mean how do you tell the difference then
# cjslep[m] How does C2S, designed first in the actor-model based ActivityPub spec, break the actor model?
# fr33domlover I like the idea of reserving Create for "publish this on my homeserver"
# fr33domlover And other activities when it's not the case
# cjslep[m] Create in an inbox is different than a Create in an outbox
# cjslep[m] One is C2S one is S2S
# fr33domlover cjslep[m], yeah but S2S is the actual network of actors and C2S is for the HTTPS-based fediverse; if your client and server were in 1 program you'd have only S2S
# cjslep[m] Create either means: C2S -> hey S can you create this; or S2S -> hi peer I created this
# fr33domlover cjslep[m], I mean C2S is for the case a remote machine hosts your stuff; otherwise it would be just S2S
# fr33domlover Say, in a p2p situation, say like SSB
# cjslep[m] I fully intend to have apcore be a C2S C, a C2S S, a S2S s1, and S2S S2
# cjslep[m] It isn't impossible for a stand alone server to be all, you just have to understand the general role you want behaviors to trigger as
# cjslep[m] A custom behavior has a server being all 4 in various parts of an applications specific need
# cjslep[m] Especially over federated networks
# cjslep[m] P2p is a transport protocol, we're talking about application design here. It could be over Https, avian carriers, postal mail, SSB
# fr33domlover Hmm I'm wondering about the following case: Suppose some kind of object, sometimes you offer it and it's automatically created, and sometimes it waits for a human to approve it. What do you do then? In C2S you instantly get a 201 Created with the activity ID, how do you tell if the object was created? Do you wait to receive an Accept whose object is the Create?
# fr33domlover That's one of the reasons I'm using Offer; it's universal in the sense that no matter what sort of permission/auth situation it is, you don't assume any guarantees, you just Offer something and wait for the Accept, whether it comes a millisecond later or a day later or never
# cjslep[m] What is the thing called your server is actually creating? It isn't an issue. It's a PendingIssue
# cjslep[m] So create that
# cjslep[m] Some servers then auto convert in their specific impl to an Issue, others wait for human approval
# cjslep[m] I think great care is needed to identify root problems and whether they can be solved by existing mechanisms and new vocabulary, or whether they really do need new mechanisms -- and in this latter case, what behavior is being introduced instead and is it scalable to more problems than the one at hand
# fr33domlover cjslep[m], that's true, you create a pending issue. And for the case you want that pending issue hosted locally for your own usage, I suggest the following: Create the issue locally, and then send an Offer with the "object" being that issue. So either way, it's an Offer, whether or not you separately published the issue with a Create. I mean, technically, a Follow is also "creation of a pending follow"
# fr33domlover and so on, you could think of *eveything* as creation of something
# cjslep[m] Sure, but that's the nature of the "creating" semantic. I think Create is better than Offer. "Offer" is ambiguous because it also has an economic meaning, so someone reading data starts to have to read the tea leaves to understand what Offer actually "means"
# fr33domlover cjslep[m], it's a matter of vocabulary. I think an Accept with a "result" is good enough to imply the object was created; and unlike the C2S thing, it just uses plain regular S2S Accept/Reject just like in the AP spec. And the spec says the side effect of an Accept depends on the type of the Accept's object, so, there's room to use types there without breaking any expectations
# fr33domlover For example "add to 'following' collection" is specific to Accept of a Follow
# cjslep[m] C2S is "plain AP"
# cjslep[m] And C2S can be used without breaking any expectations
# cjslep[m] I would get an argument against C2S if it was "it's a lot of work" or "here is where it's a problem" but these general vague complaints... I don't get.
# cjslep[m] "here where it's a problem" as in detailed spec behaviors that are undesired
# cjslep[m] But for solving a general, federated, client-wants-to-create and server-needs-to-hodt, AP C2S was explicitly designed to cover that use case, scalably
# cjslep[m] host*
# fr33domlover I'm open to this idea but I'm worried that it could end up introducing lots of weirdness and problems because C2S is for users to collect to their homeservers, that's the use case it was written for. So I just wonder, before using C2S for anything else, I'd want to be sure nothing about that usage challenges the assumptions of C2S in the spec
# fr33domlover It also feels like a hack, like you'd use C2S for this because the S2S Create is already taken
# fr33domlover Like if you has CreateOnRemoteServer, you could just use *that* in S2S between servers
# fr33domlover *had
# fr33domlover I mean, you could as well just do *everything* using C2S
# fr33domlover So I wonder, if you use C2S for this Create-remotely case, why use C2S for this specifically and S2S for everything else
# fr33domlover cwebber2, we need a spec here ^_^ I hope that lice thing in litepub gets finalized and we can just implement it and be happy
vitalyster left the channel