#social 2018-09-17
2018-09-17 UTC
vasilakisfil_, up201705417, xmpp-social, vt, vasilakisfil and jdormit joined the channel
# 
heluecht[m] Last night we had some discussion about what should be part of the activity, concerning the target that we are sending the activity to.
# heluecht[m] In my test implementation I only had some "to: ... public" in the header.
# heluecht[m] I thought this should be enough, even when sending it to the common inbox. Or should I add some more information?
# heluecht[m] There is some similar question concerning answers. Is it optional or required that in a reply you always transmit the identical values for "to" and "cc"?
# puckipedia ok so. former: you need more information. the sharedInbox is a "shorthand" for sending to e.g. all your followers on that server, you can just send them to the sharedInbox. However, sending public posts does not guarantee that they arrive
# puckipedia annoyingly, Mastodon considers the sharedInbox and normal inboxes equal, this is bad. it is hopefully fixed soon, once I have enough spoons
# puckipedia the latter: it's optional. A user can send a reply to wherever they want to send it to
# heluecht[m] Currently I do have a problem with Pleroma. It accepts my posts - and if they are an answer they arrive at the right place. But a regular post just vanishes.
# heluecht[m] On Mastodon and Hubzilla everything is fine.
# heluecht[m] And when my tests posts from the morning arrived at your system as well, then only Pleroma would be some problem.
# puckipedia this is known, and a bug on Mastodon's side
# puckipedia and Pleroma's.
# puckipedia well
# puckipedia it's known to me. because I'm the only one who actually does audience handling
# puckipedia both Pleroma and Mastodon use the audience in the post to determine who sees it
# puckipedia instead of assuming the remote server sends it to the right people
# heluecht[m] So what should I do so that it reaches the right people?
# puckipedia add the people it shuld be directed to in to/cc, and/or add the followers collection in to/cc
# puckipedia for the mastodon side of this issue, you probably have to wait for me to gain some spoons ...
# heluecht[m] I would like to use the shared inbox whenever possible.
# heluecht[m] Why spoons? Do you want to kill someone really slow?
# puckipedia heluecht[m]: "When an object is being delivered to the originating actor's followers, a server MAY reduce the number of receiving actors delivered to by identifying all followers which share the same sharedInbox who would otherwise be individual recipients and instead deliver objects to said sharedInbox."
# puckipedia so if you use the follower collection, anyone who follows the actor will get it if you send it to their sharedInbox
# puckipedia no other cases are specified.
# puckipedia and with "spoons" i mean more that I ahve a limited amount of energy currently and fixing the mastodon things is difficult
# heluecht[m] I really hate these long sentences where I forget about the beginning when I finally reached the end ;-)
# heluecht[m] So in short: When sending to the shared inbox, I always should send the follower link and/or some individual "cc" or "to".
# heluecht[m] What's with "bto" and "bcc"? Are they only for client -> server?
# puckipedia if you follow the spec, this is only for directly aimed at the follower collection
# puckipedia bto and bcc are client->server, they are not visible for other servers so you'll have to manually send them
# heluecht[m] I thought about the follower collection and cc all people that I mentioned - and to deliver it to the shared inboxes of all the servers. So that's not the way it meant to be?
# puckipedia the idea is that you then deliver it to the shared inboxes of the people in the followers, then send it to the inboxes of everyone who's mentioned separately
# heluecht[m] Even on the same server?
# puckipedia I don't think that's needed, no, but im lazy
# heluecht[m] Have you implemented it that way?
# puckipedia I implemented it that it might send it doubly
# puckipedia because complications in my code
# puckipedia anyways. ensure that you actually group by sharedInbox, those may not correspond with the host the user is on
# heluecht[m] Yeah, I know. This is no big deal on my system.
# heluecht[m] We currently are doing the same for Diaspora.
# puckipedia and yeah, ActivityPub doesn't actually have a concept of 'server'
# heluecht[m] But I guess that the reality is different to the concept.
# heluecht[m] BTW: In my current implementation I'm mostly treating the individual inboxes like the shared one - with the difference that I will use the information from the individual inboxes when there had been no individual "to".
# puckipedia basically, the sharedInbox just sends the messages to the inboxes of everyone that has that sharedInbox based on followers
# rialtate[m] sent a long message: rialtate[m]_2018-09-17_16:47:10.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/mEaJQZrqFynjxqCvJKOpZFPy>
# rialtate[m] I think the spec is crystal clear about this
# nightpool[m] I'm not sure I understand the relevance to sharedInbox?
# nightpool[m] that's the forwarding part of the spec
# rialtate[m] Lol its the "sharedinbox" part
# rialtate[m] But its about addressing not just which endpoint
# rialtate[m] And it's very clear that you can't assume addresses in the envelope
# nightpool[m] everything you quoted is from the forwarding section
# rialtate[m] sigh I give up
# rialtate[m] The sections in the spec are situational. Stuff that will help and is *mostly* relevant to that situation. I don't know why people think they are scoped like "this text only applies to the one example listed and nothing else" - that's just not how specs are written.
vasilakisfil joined the channel
# nightpool[m] sure. I also agree that addressing is important
# nightpool[m] but if you get something to *an actors individual inbox* then it's assumed that it was definitely already addressed to you, and that actor should have access to it
# nightpool[m] how else could bto or bcc work?
# heluecht[m] @rialtate:matrix.org: I know why I mostly don't really look at specs - I really do have massive understanding problems with the way they are written.
# rialtate[m] > *an actors individual inbox* then it's assumed
# rialtate[m] You're assuming there is such a thing as an individual inbox and then making additional assunptions that the spec specifically says not to
# rialtate[m] > how else could bto or bcc work?
# rialtate[m] By letting the recipient see themselves in the bcc bto, just like email.
# heluecht[m] BCC does never leave the sending mail server.
# heluecht[m] otherwise it wouldn't make any sense.
# rialtate[m] Not true
# rialtate[m] Blind means blind to everyone else, not the person its to (blindly)
# puckipedia * rialtate[m] sent a long message: rialtate[m]_2018-09-17_16:47:10.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/mEaJQZrqFynjxqCvJKOpZFPy> <- this does not apply to sharedInbox delivery indeed
# rialtate[m] I just tested it. My mailserver converted the bcc to a to before delivery.
# puckipedia mine doesn't
# rialtate[m] puckipedia where does it say don't use this information for sharedinbox? Where does it say this info applies to only one situation?
# heluecht[m] @rialtate:matrix.org: My mailserver doesn't show the BCC to me, I just tested.
# puckipedia rialtate[m]: ok so. "When Activities are received in the inbox, the server needs to forward these to recipients that the origin was unable to deliver them to. To do this, the server MUST target and deliver to the values of to, cc, and/or audience if and only if all of the following are true:" [..]
# rialtate[m] The thing that is really freaking me out right now, is that if the envelope is addressed correctly with no assumptions, it works correctly with all the existing implementations out there.
# rialtate[m] If you make all these assumptions that the spec *does not say you are allowed to make* then delivery will fail on 90% of implementations...
# rialtate[m] And yet you all are arguing that every impl has a bug rather than admitting you are making bad assumptions
# puckipedia if server B sends a reply to server A, and user B replies to user A, and user B decided "ok, send this post to user A's followers as well", then server A is required to send this post to user A's followers
# puckipedia that's all that section 7.1.2 says.
# puckipedia continuing, the issue is that ActivityPub's audience targetting is *very* flexible, and noone really bothered to implement it properly.
# heluecht[m] BTW: When doing implementations you should respect this one: https://en.wikipedia.org/wiki/Robustness_principle
# rialtate[m] Again, everyone implemented it properly from where I'm sitting
# heluecht[m] "TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others."
# rialtate[m] It works perfectly when you don't make assumptions no one said you are allowed to make!
# puckipedia i'm writing up a small thing
# nightpool[m] @rialtate:matrix.org: i think it's fair to say that you're the one who's making bad assumptions here
# nightpool[m] when multiple of the implementors you're citing are in this room telling you you're wrong.
# rialtate[m] heluecht: being conservative in what you send does not mean leaving off stuff and hoping the destination made the same assumptions that you are pulling out your butt. Quite the opposite.
# nightpool[m] sent a long message: nightpool[m]_2018-09-17_17:37:42.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/xeiCzTVftVDoDbhUzAKzQWjM>
# rialtate[m] nightpool: when those implements actually work!
# nightpool[m] sorry that formatting was bad here it is again:
# nightpool[m] >An HTTP POST request (with authorization of the submitting user) is then made to the inbox, with the Activity as the body of the request. This Activity is added by the receiver as an item in the inbox OrderedCollection. Attempts to deliver to an inbox on a non-federated server SHOULD result in a 405 Method Not Allowed response.
# nightpool[m] if something is posted to your inbox, you add it to your inbox OrderedCollection
# nightpool[m] now, mastodon doesn't currently do this but that was an explicit choice we made to be non-compatible
# puckipedia heluecht[m]: rialtate[m]: https://gist.github.com/puckipedia/9e0bffb93cbb5053e47570fd0c7258c0
# puckipedia I am 100% compatible with Mastodon by implementing the proper algorithms
# nightpool[m] yes sorry non-compatible was not the correct word choice
# nightpool[m] also re bto/bcc:
# nightpool[m] >The server MUST remove the bto and/or bcc properties, if they exist, from the ActivityStreams object before delivery, but MUST utilize the addressing originally stored on the bto / bcc properties for determining recipients in delivery.
# nightpool[m] this is in the client-server spec. so it's assumed that s2s receiving activities will *not* have the bto/bcc properties available
# rialtate[m] nightpool: and that is from the clientcserver section, and is written in a way that makes it clear that it does apply only to that situation.
# rialtate[m] Omg you people are so backwards
# puckipedia rialtate[m]: oh so if the server magicks up the bto/bcc values it should send it to other servers great plan
# puckipedia i'd like to see the issue tracker for that
# puckipedia "bto/bcc get leaked" "not an issue"
# nightpool[m] @rialtate:matrix.org: yes, it applies to the client -> server step
# nightpool[m] the full flow goes client -> server -> remote server
# puckipedia rialtate[m]: https://www.w3.org/TR/activitypub/#security-not-displaying-bto-bcc
# nightpool[m] so if the bto/bcc gets removed during client -> server how will it ever be available to the remote server
# nightpool[m] ?
# rialtate[m] facepalm
# puckipedia i feel like almost everyone has issues with the audience thing just because it's so flexible
# rialtate[m] puckipedia: and I feel like the only ones having issues are the ones pulling assumptions out their butt
# rialtate[m] I'll say it a 3rd time a 3rd way so maybe it sinks in. There is no situation where delivery fails when you don't make the assumptions. When you insist there should be assumptions then problems occur. Occams razor says that the assumptions are the problem. Not that everyone is buggy for not making more of them.
# puckipedia I make zero assumptions. I send it to the sharedInbox of my followers if I address my followers, and send it to the inbox of everyone else
# puckipedia same with receiving sharedInbox (once that's 100% up and running again). I just check the followers collection, and send it to the people who follow that person
kaniini joined the channel
# heluecht[m] is there any difference in the treatment of "to" and "cc"?
# heluecht[m] I'm currently working on the permission block that translates the Friendica permissions into some AP compatible thingy.
# puckipedia same difference as in email
# heluecht[m] I would - by now - just adding everyone in "cc" - except persons that I directly mentioned (or public)
# puckipedia that's basically what everyone does
# heluecht[m] The directly mentioned persons would be put into "to"
# puckipedia if the post is public, put https://www.w3.org/ns/activitystreams#Public in to, if it's unlisted, put it in cc
# heluecht[m] And when doing public posts, I would also add the follower collection to the data - and leave out any "cc" (but add the "to" as well)
# puckipedia I would suggest putting every mention on public posts in cc too
# heluecht[m] Why?
# puckipedia because what if you're trying to mention someone on a server where noone follows you?
# heluecht[m] Where's the problem?
# puckipedia it'd not get sent to their sharedInbox, because there's noone on their server that's in the followers collection
# heluecht[m] Just to explain: I'm sometimes really stupid in understanding this stuff :-D
# heluecht[m] So you would treat "cc" and "to differently upon receiving the post?
# puckipedia I do not do that
# puckipedia but
# puckipedia like, only the people that are in the audience will get the post
# puckipedia so if you send it to the user's followers, only they get the post
# heluecht[m] I don't really understand by now, but you recommend: Private post: Mentioned => "to", rest in "cc". Public post: Public and followers in "to", mentioned in "cc", right?
# heluecht[m] And when there are no mentioned ones in private posts then I send an empty "to" and the rest in "cc"?
# puckipedia for example
# puckipedia there's no real hard guidelines you need to follow
# puckipedia assume that "to" has higher priority over cc i guess
# heluecht[m] So possibly I should never have an empty "to"?
vt joined the channel; vt left the channel
# puckipedia lol. reading my "i made a forum" thread takes ehm. 85 requests
# heluecht[m] BTW: Is there some maximum length for an actor's url?
# puckipedia practically: no. technically: well the spec says no. but like, you'll hit issues after a certain length just because databases
# heluecht[m] Yeah, exactly. I guess I will create a new table, just for AP contacts. This does make sense since Hubzilla-, Friendica- and OStatus-servers could be AP compatible as well.
# rialtate[m] I think HTTP sets max url len at 255 (253 actual).. Unless I'm remembering incorrectly
# JasonRobinson[m] url's can be thousands of chars long
# JasonRobinson[m] some browsers like old IE versions don't like really long ones tho
# rialtate[m] Local uris can be. Up to 64k I think, for datauri scheme
# rialtate[m] But HTTP limits it
# JasonRobinson[m] https://stackoverflow.com/a/417184/1489738
# JasonRobinson[m] standards <3 ;)
# rialtate[m] Hmm... I wonder which protocol I'm remembering then. I only read it like a week ago... Stuff gets fuzzy when you implement 6 diff protocols in one week though :)
# JasonRobinson[m] I remember once debugging a weird bug that customers were reporting a long time ago and it ended up being IE cutting a part of the URL of the ajax requests it sent out because they went over 2K or something :D
# heluecht[m] But noone - hopefully - will have so long AP profiles.
# rialtate[m] Meh. Just use a grownup db like postgres and you're fine. :)
# heluecht[m] @rialtate:matrix.org: We are using MySQL since our aim is that Friendica can even run on shared hosters. They mostly offer MySQL, but Postgres not so often.
# rialtate[m] Hah yeah just poking fun anyway.
# rialtate[m] Realistically I don't think anyone will design their system with 1000+ chars and then complain when it doesn't federate.
# rialtate[m] Well this is the internet so there will always be that jerk but we don't have to give them heed
# JasonRobinson[m] +1 totally. just wanted to point out not at all related to AP ID's how long urls can be
# saranix you know what would be neat? packing a DID into a datauri actor; literal content-based addressing :-) You would need some kind of signature to validate the integrity of the public key, but other than that...
# puckipedia saranix: i ehm, have thought about this indeed lol
# saranix puckipedia: I kind of had a hunch it was down your alley ;-)
# puckipedia saranix: haha. i've got some really fun cursed things i've tried
# saranix puckipedia: like what else?
# puckipedia to be precise:
{"type": ["Create", "Note"], "id": "https://something", "object": "https://something"}# saranix puckipedia: haha I did that one too!