#social 2017-07-29
2017-07-29 UTC
geppy joined the channel
# 
geppy I know rhiaro has been researching and linking to information on privacy (empowering users, responsible data collection, etc.), but I seem to have misplaced my bookmarks. Can anyone point me to resources on data minimization and especially on human-friendly privacy controls?
xmpp-social and geppy joined the channel
# 
ajordan csarven: AHHHHHHHH. I saw geppy's message and *immediately* thought of that, but I thought it was http://doctor.amy.gy
# ajordan and I got *very* confused because that returns 503 Service Temporarily Unavailable, and then http://amy.gy is just a poop emoji
timbl joined the channel
# xmpp-social [ajordan] ah nvm then
# xmpp-social [ajordan] But on the bright side, at least I printed 30 double-sided pages of spec to read :P
# xmpp-social [ajordan] Or dark side, depending on how you look at it
# puckipedia wo, I think I have implemented a sharedInbox
# puckipedia for receiving at least
# puckipedia woops I also added delivery to sharedInbox too
ben_thatmust and ben_thatmustbeme joined the channel
# xmpp-social [ajordan] puckipedia: sweet \o/
# puckipedia fun fact, it eventually turned out to be less work to implement delivery than to implement receiving
# puckipedia my processing basically builds a queue of items to work through, and each queue item has the actor/collection, a depth, and now a flag if it is a follower collection
# puckipedia so when a follower collection is processed through the queue, each actor in there gets a flag that it should prefer the sharedInbox
# puckipedia this means that if you do e.g. to: ["user/following", "userB"] and userB follows user, it delivers it once to sharedInbox and once to the inbox itself
# puckipedia which is, afaik, mostly correct behavior?
# saranix my whole point of view has been that the entire point of the sharedinbox endpoint is to guarantee reduced unnecessary duplicate traffic. I think other people wanted it for other reasons...
# saranix more precisely I just wanted an endpoint that guarantees delivery to all possible recipients because of the weasel words in the current inbox delivery definition.
# puckipedia the plan is that sharedInbox will guarantee delivery to all followers, as that's the only thing that's synchronized between servers
# saranix not so funnily, followers collection is probably the only thing that *isn't* synchronized between servers for my software usecase (and also the hubzilla model, and quite frankly the diaspora model but I don't think they realize it)
# puckipedia wait, you don't ensure that the server of the person you're following knows you're following them?
# saranix not really
# saranix for a variety of privacy reasons it isn't guaranteed
# puckipedia well, I mean, if you mean the google+ "post to collection" mechanism
# saranix you'll lose me on silo comparisons. I've never used that garbage and I find it all very lacking.
# puckipedia sharedInbox currently only works for the special follower/following actor attributes. and the idea is that follows are required to be accepted/rejected, in order to verify that both servers are 100% sure of whether a specific user is following another user
# saranix which I've said from the beginning is completely pointless. Because it can be done with the existing inbox. The whole thing to me is bass ackwards.
# saranix it's putting really bad usecase semantics into the protocol
# xmpp-social [ajordan] What can be done with regular inbox? Distributing to the special followers collection?
# puckipedia the point is that some systems (Mastodon, Diaspora) have a separate mechanism for messages sent directly to a person, and messages sent to followers
# puckipedia (was it Diaspora?)
# saranix I don't want to start a whole thing. I don't have time to be digging out links and stuff
# saranix I'm going to use the siteinbox for what I think is the only logical use, as an extension, in my implementation. I think once others see how I'm doing it, at least one other person will copy. I'd be fine with that.
# saranix I certainly WILL NOT support the sloppy definition of "followers-only" because that is like I said backwards.
# saranix It only compounds the bad definition of the existing inbox delivery rather than fixing it
# xmpp-social [ajordan] saranix: you still haven't explained what actual problems you see...
# xmpp-social [ajordan] Like, why is sharedInbox broken? How is it catering to bad use cases?
# saranix I have actually. It makes assumptions that are only true in basically the Mastodon usecase, which is not representative of all usecases
# saranix not bad usecases
# saranix imposing one single usecase on everyone
# puckipedia also Diaspora, and, well, kiiinda Facebook
# saranix which is bad
# saranix like I said, Diaspora actually follows the hubzilla model, they just don't realize it
# xmpp-social [ajordan] There are very non-trivial problems with getting this right
# saranix facebook isn't federated so it's not a real comparison
# xmpp-social [ajordan] The current behavior is a compromise between complexity and optimization
# saranix of course they have perfect knowledge of all parts of the system, they are a silo
# puckipedia saranix: well, I mean, the way Facebook works is you 'befriend' other users, and that sets up a two-way follower/following
# saranix I just explained why facebook is a completely invalid comparison
# saranix There is no foreign server
# saranix it is all local
# saranix completely different thing
# saranix completely different concerns
# saranix completely different privacy model
# saranix as in no privacy :-P
# saranix So it seems hubzilla has publicly declared they are not implementing activitypub anymore. Which is a shame. But any software I write is going to be compatible with Zot and with the same strict privacy model. So when I implement ActivityPub I'm doing it in such a way that it still works. Even if that means I end up non-compliant somehow...
# puckipedia so if I'm reading the way zot works properly I would consider the sharedInbox as being considered now good enough to implement zot
# puckipedia the recipients array is only passed when it's a private message
# saranix It seems that zotlabs has a completely different view on this particular issue than I do
# xmpp-social [ajordan] Friendly reminder that AS2 audience targeting has bcc and bto
# saranix not contrary to my view, still antagonistic towards activitypub but for different reasons
# xmpp-social [ajordan] Which it seems like such a private implementation would find useful :)
# saranix ajordan: this is how I handle it, I'm not sure about what zotlabs is concerned about
# puckipedia saranix: tbh, as long as you can fall back to non-siteInbox I don't see why you couldn't just use it, as it'd be an extension anyways
# saranix oh hahahaha wait a minute, it seems zotlabs is thinking like me in at least some ways: https://macgirvin.com/channel/mike/?f=&mid=b66a33eab46047c3ebfaa1d0a9306856587a0880eff7445c724f92fef55e2d31@macgirvin.com
# saranix I can't find the message from like 2 days ago where he rants and says he is ripping out activitypub. I don't remember the reason but I do remember it was actually something I think is a non-issue.
# xmpp-social [ajordan] https://discourse.diasporafoundation.org/t/lets-talk-about-activitypub/741/8 lots of criticism from the diaspora* people
# xmpp-social [ajordan] Particularly about interop
# xmpp-social [ajordan] cwebber2, sandro: ^^^
# xmpp-social [ajordan] saranix: that post makes no sense to me tbh
# xmpp-social [ajordan] No details, just a bunch of talk and buzzwords
# saranix funny thing is I think the diaspora protocol is a better protocol than ActivityPub... from a technical standpoint.
# xmpp-social [ajordan] Tbh a lot of things in that feed annoy me, like the way the author condescendingly says that his proposed auth solution will make the AP people "hate [him] big-time"
# xmpp-social [ajordan] Like... no? Just propose it and we'll debate it on its technical merits?
# puckipedia indeed
# saranix yeah he's a bit crude
# xmpp-social [ajordan] *sigh* maybe this is just what being in standards gets you but. It's still really seriously rude
# saranix but I understand him, and his frustration
# saranix he's spent way more of his life on this stuff than I have, and I've spent a lot
# puckipedia I'm wondering if nomadic identity doesn't make it way easier for you to get hacked
# puckipedia well, either that or nomadic identity isn't that effective...?
# saranix I'm a very optimistic person. I also see this from a different perspective. While he's trying to cram more advanced features into simpler protocols, I've actually had to do the same with my protocol-- it's more advanced than Zot. So I see it from the other direction a bit.
# xmpp-social [ajordan] On a COMPLETELY unrelated note one thing that I keep revisiting is an elegant search extension
# xmpp-social [ajordan] And I just realized that actually what we might want to do is just standardize a GraphQL endpoint
# xmpp-social [ajordan] Because that would by its very nature provide all the flexibility I think we want
tOkeshu joined the channel
# tOkeshu ahoy o/
# tOkeshu cwebber2: thanks for your answer. Is right now a good moment to ask question?
tOkeshu and tOkeshu1 joined the channel