#social 2018-07-17
2018-07-17 UTC
timbl joined the channel
# 
saranix widowclip: sounds like a job for ocap/caveats
xmpp-social, vasilakisfil, fr33domlover, timbl and JanKusanagi joined the channel
# puckipedia woo
tantek joined the channel
tantek and cwebber2 joined the channel
# puckipedia cwebber2: kroeg-rs is doing pretty well also
cwebber2 joined the channel
# dansup puckipedia: Nice! I'm almost done basic federation support (masto/pleroma) for pixelfed :D
cwebber2 joined the channel
# puckipedia dansup: it's taken quite a bit but I trust that this code is pretty sturdy, there's a few panic/unwraps still but that's because I'm slightly lazy
cwebber2 joined the channel
# fr33domlover If I have an activity that creates an object but the object is created on a remote server, not my local server where my account is: Should I define a new CreateOnDestination activity for that? I feel like if I use regular Create, it's ambiguous because a generic AP server will mistakenly create locally, not being aware I wanted to create on destination
# 
Loqi fr33domlover: saranix left you a message 1 day, 15 hours ago: ping timeout looks like it may be coming from server side. in IRC lingo, that means literally a PING timeout. That is, a PING without a valid PONG. AFAICR it is supposed to be verbatim but it may be possible a clock skew or poorly coded client could cause problems
# puckipedia fr33domlover: please do not
# puckipedia fr33domlover: I use
{"type": "Create", "object": "https://example.com/asdf"} to explicitly indicate that the object isn't local# puckipedia as soon as you imply the contents it becomes local
# puckipedia I think this is an acceptable reading
# fr33domlover puckipedia, hmmmm note that when server A sends such a thing to server B to create, server A can't assign an ID yet because server B is the one who decides the ID
# 
jaywink[m] cwebber2: what do you think about this "creating remote objects" thing? I really think it's a troublesome way to work. The idea that there is, which I don't like, is to post a PR to another server by "creating" it remotely. It really doesn't feel right for authors to be creating objects which they don't even have an ID for and have no control about.
# fr33domlover puckipedia, so how do I indicate the object should be created remotely? drop the ID field?
# fr33domlover puckipedia, also btw what's wrong with a new custom activity? Just curious :) (btw I'm extending AS2 either way)
# jaywink[m] fr33domlover: for the issues this solves, it creates way more problems IMHO
# puckipedia creating remote objects with a custom activity means that all other servers need to understand it as well
# jaywink[m] I'm not even sure what it solves :)
# puckipedia jaywink[m]: in e.g. federated git, you'd want the server hosting the repo to own the issues
# puckipedia fr33domlover: I would say
{type: Create, object: remote_id} would be fine as long as the object is normally ok. if you do {type: Create, object: {type: Note, ...}} it'd imply a local object# jaywink[m] every server owns their local copy - you don't need to make hacks for that
# fr33domlover puckipedia, I don't know the remote ID in advance: It'a assigned only after that request is made
# puckipedia fr33domlover: don't
# jaywink[m] and the server who owns the repo has the authorative say on what issues/PR's the repo has - doesn't matter where they came from
# puckipedia jaywink[m]: I 'owning' as in 'having the authoritative copy'
# fr33domlover puckipedia, don't what? ^_^
# puckipedia jaywink[m]: yes, but the server owning the repo should also have the say on when issues are closed
# puckipedia fr33domlover: don't do that
# jaywink[m] puckipedia: so post a close activity out
# puckipedia jaywink[m]: ok so
# jaywink[m] you don't need to be creator of an object to be able to send activities related to it
# fr33domlover puckipedia, what choice do I have? Server A doesn't know the algorithm server B uses to assign the ID. So how can it know the ID in advance
# puckipedia fr33domlover: it will generate the ID on its own domain
# fr33domlover puckipedia, like a temporary fake one?
# puckipedia fr33domlover: no.
# puckipedia jaywink[m]: now, servers that have not seen the Close activity will retrieve the issue from server A, which still says it's open
# puckipedia fr33domlover: server A creates an object with ID, posts to user on server B's outbox saying
{type: Create, object: serverB/user/object}# jaywink[m] puckipedia: how would other servers even know to retrieve an issue from the third server? would they not check the repository outbox?
# fr33domlover puckipedia, example: Suppose I want the ID to be https://x.y/project/issues/217 to generate it, server B knows the number of the last issue opened. But server A doesn't, it can't generate that ID by itself)
vasilakisfil joined the channel
# jaywink[m] sorry issues collection
# puckipedia jaywink[m]: they would probably look at an 'issues' collection, but, good servers won't trust the contents of an object hosted on another server if embedded
# puckipedia so they will verify with the authoritative server, which says "nah it's still open"
# jaywink[m] for the problem of possible different information around the web (it will happen anyway, nothing is 100% in sync in a federated network), this will create an awful lot of problems
# jaywink[m] puckipedia: well, this is an extension to AP. I think the protocol spec could easily define that the repository collections should be trusted, as should be activities by the repository on objects that target it
# jaywink[m] much simpler
# puckipedia noooooo
# puckipedia because now
# puckipedia imagine I don't actually put an issue in my issues collection
# jaywink[m] why would any other server trust the repository when it sends out an issue authored by someone but the ID points to another actor?
# jaywink[m] the repository owner could create issues on behalf of anyone
# puckipedia this could be more easily fixable, by having a signed/authoriatite create activity linked in the object, in in the right place
# jaywink[m] "puckipedia created an issue on socialhome saying it sucks" - the object is fully controlled by the repository - it could say anything :)
# puckipedia egh
# puckipedia so I feel like the best way to do this now
# fr33domlover (1) signatures like puckipedia said (2) it matters much less who made the issue
# puckipedia fr33domlover: I see jaywink[m]'s point though
# fr33domlover Issues are about their value to the project
# puckipedia the best way might just be having an issue on the repo server, pointing to the issue on the actor's server
# jaywink[m] so what happens on update if the repository owner updates it? the original author would have to approve and resign it
# puckipedia i meant signing the Create, not the Issue
# fr33domlover puckipedia, yeah me too, we talked about this and it seems both approaches have their pros and cons :-/
# fr33domlover I'm still unsure which one to pick tbh
# puckipedia and yeah, we should probably keep this discussion for tomorrow lol
# fr33domlover Just exploring both
# jaywink[m] would be good to have on call indeed, more people then
# fr33domlover jaywink[m], one there's an update, the original author isn't responsible for the new content. Either way they still signed the original, and the Update is the repo owner's problem
# jaywink[m] fr33domlover: seems harsh if the repo owner just fixes a one letter typo and suddenly you can't verify it was from the original author :)
# fr33domlover jaywink[m], what if you can using the original signature + look at the diff of the Update
# fr33domlover But yeah it's a good point
# fr33domlover jaywink[m], we have the same problem without federation: I open an issue on your repo, you decide to edit it, now how do we tell how much text is you, how much is me, how much got deleted
# fr33domlover So if by default the situation stayed the same, we don't lose anything
# fr33domlover jaywink[m], once an issue is opened on a repo, the devs may wish to control who is allowed to make which changes. That's the problem. Maybe they want to keep your text as is, and still see that text evem if you feel like deleteing half of it
# fr33domlover (Because the original is useful to them as is)
# jaywink[m] sure, but it means the signature solution is flaky and only works without an edit. if the repo makes an update and just sends it to the original author, then the original author can either use it or keep their version. it's a much simpler thing to implement than some custom-for-this-spec-only author signatures
# jaywink[m] edits are always problematic in any situation
# jaywink[m] fr33domlover: then they should implement versioning ;)
# jaywink[m] locally
# jaywink[m] issue locking is also a feature on github etc. that should probably block edits from the original author too
# fr33domlover jaywink[m], agreed, but if the original author doesn't accept the edit we have a problem: The official ID points to a version of the issue that isn't the one that the repo devs actually have, that's confusing. How about hmmm what if you create an issue locally, and when it reaches the repo server it makes a copy with a new ID and that's the one they control and edit freely
# fr33domlover Like, you have your regular object you Created, just like a Note
# fr33domlover Except additionally, a copy of it with a new ID is created on the repo server
# jaywink[m] fr33domlover: that is no different than posting the issue without an id?
# fr33domlover jaywink[m], I mean post is exactly like you post a Note. I just mean, 2 objects will be created. Your local issue just like a Note, and in *addition* the repo server makes a local copy with a separate local ID
# jaywink[m] cwebber2: no, speaking of local objects to be created remotely. so context: a Pull Request
# fr33domlover cwebber2, backlog includes previous few days of discussion ^_^
# jaywink[m] so, server A would create an object on server B (a pull request) without assigning an ID. the create would point to server A and the object ID would (at some point after the create) point to server B
# fr33domlover Hmm jaywink[m] I like this idea a lot: Regular plain Create + repo server makes a copy that is the official version in the repo (and that copy can still accept your Updates but at least the repo devs have a final say on their copy etc.)
# jaywink[m] actor on server A is the author actor, but has no control of the obejct, nor does the object ID point to their server
# fr33domlover thinks he may have just found a reasonable solution in the middle
# fr33domlover cwebber2, permissions
# jaywink[m] fr33domlover: I suuppose you could have a "createdFrom" property pass to the original object. so better
# fr33domlover cwebber2, e.g. repo devs decide only repo team is allowed to make edits etc.
# jaywink[m] cwebber2: my point exactly, I think it should :)
# fr33domlover cwebber2, well ocaps is just the language! the problem would be that the devs don't have a final say
# fr33domlover jaywink[m], yeah so you still have a sig on the original version and everything!
# fr33domlover And the one in the repo can refer to it
# jaywink[m] oh this is not gitpub, it's #peers work (freenode)
fr33domlover joined the channel
# fr33domlover 's IRC client suddenly stopped responding to the keyboard, weird!
# fr33domlover I'm happy to have all this discussion!!
# fr33domlover With all of you people
# fr33domlover 2 objects seems like the best to me atm
# fr33domlover Author has control over what they say
# fr33domlover And repo devs have control over their list of issues
# fr33domlover So everyone is happy
# jaywink[m] feels a bit dirty still but less dirty :) seems to have the leaast problems
# fr33domlover jaywink[m], both of the other options require special support on the sending side, that's a lot of dirty indeed :p
# fr33domlover cwebber2, yeah I am ^_^
# fr33domlover I'll see if I can be on the call etc.
# fr33domlover cwebber2, I'm very curious about ocap-ld!! To have some standard way for servers to communicate and verify that activities are authorized and so on, I only read ocap-ld intro and I want to read more
# fr33domlover cwebber2, so far in the web app I'm making, I'm using RBAC (with role inheritance) which seems powerful and flexible to me, but, there's no federation yet, so I suppose possibly I'll need to translate that system into something that can be communicated between servers etc.
timbl joined the channel