#social 2017-11-29
2017-11-29 UTC
# 
Loqi Tantekelik made 1 edit to [[Socialwg/2017-11-28]] https://www.w3.org/wiki/index.php?diff=105271&oldid=105266
tantek joined the channel
# 
tantek agenda up for next week's telcon https://www.w3.org/wiki/Socialwg/2017-12-05
# Loqi Tantekelik made 2 edits to [[Socialwg/2017-12-05]] https://www.w3.org/wiki/index.php?diff=105273&oldid=0
# Loqi Tantekelik made 2 edits to [[Socialwg]] https://www.w3.org/wiki/index.php?diff=105275&oldid=105262
tantek, cdchapman, rowan, xmpp-social and timbl joined the channel
# 
Chocobozzz hi, sorry but i have another question :)
# Chocobozzz In my video platform, we have the concept of video channels. A video channel contains 0..n videos. But a video has to be in a video channel. So I send an 'Add' activity to the followers.
# Chocobozzz But maybe other video platforms (or on a social network) don't have the video channel concept. So should they handle the 'Add' like a 'Create'? Or is it to me to send an 'Add' activity + a 'Create' activity?
rowan joined the channel
# puckipedia Chocobozzz: I would suggesting a user Create'ing a video, and a channel Announce'ing it
# Chocobozzz puckipedia: hi :) are you sure? amho a channel is a collection, so the Add seems more relevant
# puckipedia so IMO: a channel has a main video stream, and can have many playlists
# puckipedia and you want to be able to follow a channel
# puckipedia so the channel has to be an actor, so it can send events to others
# Chocobozzz puckipedia: and what about the user?
# Chocobozzz that have one or many channels?
# puckipedia wait, can multiple users control one channel?
# Chocobozzz for now no, but maybe in the future yes
# puckipedia so yeah, I would suggest having the channel be a separate actor that can be followed
# Chocobozzz puckipedia: okay and how do you link the channel and the account?
# Chocobozzz account or user, that is already an actor
# puckipedia you mean in the AS2? you could have a collection "owners" or something. honestly, I am also just kind of improvising things here
# Chocobozzz okay :)
timbl joined the channel
# puckipedia so like most everything in activitypub, you're treading in unknown territory, so you'll have to try out what fits best and what will probably have the best compatibility with other things
# puckipedia oh and btw, Add doesn't notify the channel, and though you could give a collection an outbox, it's probably not well supported lol
# Chocobozzz puckipedia: yes you're right ^^ I don't really like to have a channel has an actor but you got a point with the following channel feature
timbl_ and rowan joined the channel
# saranix It really should be possible to Follow only a collection. The problem is ActivityPub is based around a very naive idea of "friends" and "connections" and well, microblogging really...
# puckipedia saranix: I mean, it will probably be possible but we haven't fleshed out the details exactly
# puckipedia cwebber2 had the most brilliant idea that made me facepalm: why can't we give collections an inbox
# puckipedia so instead of manually delivering to e.g. the users in a collection, just send it to its inbox
# saranix to me "inbox" and "outbox" are facepalms :-P
# puckipedia and with collections having inboxes, making something "friend-circle"-like wouldn't be too difficult
# saranix it's reinventing whilst simultaneously convoluting and abstracting WebDAV
# saranix without permissions or anything else that would make it tolerable
# puckipedia saranix: there's nothing stopping you of limiting the inbox to only a specific group of people
# saranix you're missing the point
# saranix the stream (collection) itself is the inbox (or should be), same with an Actor. The whole inbox thing is just a giant mess.
# puckipedia so in the case of friend-circle style things, I'd have the content of the collection be the people in that 'circle'. then an inbox where you send messages that have to be delivered to everyone in that circle
# saranix The problem is that inbox is a collection, so following the inbox logic, inbox should have an inbox, and that inbox should have an inbox, and that inbox should have an inbox, to infinity
# puckipedia not all collections have to have inboxes
# saranix but logically they do
# puckipedia why would they?
# saranix so people can add to them and follow them
# saranix my point is, inbox is stupid.
# saranix always has been, but this just illustrates it quite obviously
# puckipedia tbh I would limit following/(adding is a weird situation, I actually don't do federated add/remove yet) to specific collections by flagging them
# saranix so does the whole sharedInbox family of arguments, none of those things would be problems if inboxes weren't the delivery method, and people could just operate directly on the thing they are operating on without all these rediculous semantics getting in the way
# puckipedia and wait hm oh yeah I think I see where you're going ... I assumed more of a one-sided push, while you're thinking one-sided pull
# saranix I'm thinking, if I'm posting on somebody's "wall", I'm putting a post in their wall, I'm not delivering to their inbox so that they can put it on their wall. Either I have permission or I don't, the inbox adds nothing but gets in the way.
# saranix everything has to be re-routed just so that we can call it inbox
# saranix outbox is thrice as rediculous
# puckipedia so a reason you would want inbox/outbox separately, is so you can have a static hosting for most of your objects, and then dynamically host (maybe somewhere else even) your inbox/outbox delivery
# saranix Except that's not how any federated social software works. It's how indieweb people like to do things, all 2 dozen of them, but the entire rest of the world.........
# puckipedia well, you also have MX records, right?
# saranix you mean a Host actor, like activitypub DOESN'T have? yes.
# puckipedia I mean, delegating inbox/outbox to another server. while still keeping local addresses
# saranix it delegates, doesn't change the entire address. I don't have to route my email to their MX, to their inbox
# puckipedia imagine being able to host a file on your server, then having it point to another server that handles the inbox/outbox
# saranix you're helping make my point about how stupid and rediculous an inbox is
# puckipedia
{"id": "https://example.com/", "inbox": "https://mailserver.com"}# saranix hmm... the insanity could be avoided I suppose if the inbox was always the same as the address. Would that cause any problems or ambiguity with the protocol as is? I can't think of any offhand. So like
{"id":"https://example.com/someblog/", "inbox": "https://example.com/someblog/", outbox: "https://example.com/someblog" } ...# saranix that should work, right?
# saranix I mean if it really is just a "who processes it" pointer...
# puckipedia that should be allowed, though there's a SHOULD for the inbox/outbox to be a collection
# saranix it usually is
# saranix a blog or whatever already is a collection
# puckipedia true
# puckipedia I don't actually think either Mastodon or Kroeg depend on it
# saranix that's part of why the whole inbox thing is convoluted
# saranix it's really just another symptom of not having a host actor actually. Because normally, a pointer to the input processing url would be a property of the host, and the host would be a property of the social channel (i.e. webfinger), but now we're dangling all the host information off of every endpoint. I think the part that bothers me is how it is worded and calling it an "inbox".
# saranix also acting like it's an AS object in it's own right when really it's just an endpoint
# saranix that's where you get into the infinite recursion thing
# saranix cwebber2: I know that
# saranix you can though, right?
# saranix I didn't say "what about an inbox with an inbox", I said "then an inbox needs an inbox", because it is a collection
# saranix it's pointing out the logic error
# 
cwebber2 re: how to have multiple participants curate a Collection on a distributed network, I don't think AP currently has an answer to it, but that's one reason I'm working on ld-ocap, which I think can hopefully fill that gap https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/lds-ocap/lds-ocap.md
# saranix you're missing the point
# saranix the infinite recursion problem comes into play because the inbox itself is an AS2 object itself
# saranix instead of just being an endpoint, like it looks like it's logically meant to be
# saranix that's not the problem
# saranix the problem is logically it should to make things consistent, so in order to not have a problem you have to be inconsistent, that's a problem.
# saranix yes.
# saranix more than just conceptually, in practice
# saranix especially in practice
# saranix almost like whoever came up with it, never tried it :-P
# saranix I have, every step of the way
# saranix because you only tried the usecase that fits it
# saranix that's actually more directly my point, it is very narrow
# saranix I hate to keep bringing this up, but, bigoted...
# saranix *sigh*
# saranix I have to work
# saranix It's very frustrating, when I have this point of view... I see yours, very clearly, that's not the problem, but I also see others... not just my own, but others... many others... and yet the people in here only ever seem to see their own. Very frustrating.
# saranix that's not my frustration, I'd run away if I thought that people's hearts weren't in the right place. The frustration comes from not only being the minority voice, but finding myself having to be the representation for a zillion other minority voices which are ALSO being ignored...
# saranix it's like I have to constantly explain that there's this whole other world out there, and not just that, but that I'm basically never believed... like I have to PROVE that there's this whole other world out there
# saranix The way I wish things were, is that we could all sit down and develope the technically best protocol, right now Zot is in a league of it's own and it's not even a new protocol, it's been around for years
# saranix well it's that you think it isn't a problem and can't see how it's a problem, the reason is, a basic ignorance of how other softwares work
# saranix it's a minor problem, but the lack of perspective is kind of major
# saranix A possible solution that I thought of before we got off track, was for me to publish my own translation of the standard, a simplified version that people who come from other perspectives can much more easily follow. However, that's really only worth doing if ActivityPub is a protocol specifically engineered to be the best. and it wasn't. It wasn't even engineered really. It was more like sculpted, based on a small subset of related implementations.
# saranix which from what I gather is just how w3c is chartered to do things
# saranix I understand that, quite well. Most others in the world are quite surprised when I explain it to them though.
rowan_ joined the channel
# saranix cwebber2 ha. I appreciate the effort
# saranix agh
# saranix hands are full
# cwebber2 in other news https://blog.tokenize.com/fido-2-0-what-is-it-and-why-are-we-excited-31a66df6e113 sounds exciting indeed... I'd love to reduce reliance on my password manager
# saranix lol for a second I thought it was a hipster revival of FidoNET then from your comment I realized I know what FIDO 2.0 is ;-)
# saranix yes it would, it would probably look a lot like activitypub actually
# saranix the low-bandwidth protocols of yore are actually very fun with new tech. like $25 pocketbone doing ax.25 in the Megabits range :-D
# saranix yeah, the old neurons are glowing
# saranix if I was born to the right social class, I could hack up a very terrible bluetooth version of it that runs on iphone and bring it to burning man and make the front page of hacker news... oh wait, someone already did that
# 
aaronpk I still need to figure out what i'm missing trying to get my raspberry pi radio interface hooked up to transmit. right now I can receive only. https://w7apk.com/aprs
# saranix wants
# saranix not sure how realistic it is for me to want such a thing (as if I don't have a billion projects I don't have time for)
# saranix how would we do it?
# saranix err...but what makes it "social"? and are we just doing ip over ax.25? that's boring... something more direct is more fun IMHO
# saranix well, direct protocol-wise. relaying is cool too
# aaronpk I started thinking about it but quickly got out of my depths on how signature/hashing mechanisms actually work https://w7apk.com/radio-authentication
# saranix encryption is allowed, that's a fallacy. just metadata (callsign) has to be plaintext
# saranix tons of articles about it, probabl ARRL related
# saranix it's near impossible to prevent commercial use with encryption, but realistically the whole thing is pretty "light touch" as far as regulations go. There aren't a lot of pirates mucking things up.
# saranix I think people are much more conservative with the amount they transmit when it's all plaintext too
# saranix if people didn't care that it was public, they might transfer large files etc. and clog up airwaves
# saranix but anyway for our purposes, we just need hashes which is legal
# saranix it is legal for hams to transmit on one of the 802.11g wifi channels at like 100 watts or something I forget ;-) so you don't need to only go 1200bps
# saranix plus there's the whole "bleeding edge experimental modes" part of ham
# saranix physical constraints? http://beagleboard.org/pocket https://www.pjrc.com/store/teensy32.html
# saranix can even drive a VGA display with those things
# cwebber2 someone's giving a talk on ActivityPub + Ruby in Madrid https://mastodon.social/@ortegacmanuel/99088764525835861
# Loqi [Manuel Ortega] Tomorrow #ActivityPub at Madrid's Ruby meetup http://www.madridrb.com/topics/mini-implementacion-de-activitypub-en-ruby-567 Here the code we will be showcasing https://github.com/ortegacmanuel/hanatachi/tree/miniactivitypub#getting-started
tantek joined the channel
# aaronpk went down quite a rabbit hole just now http://www.hsmm-mesh.org/ http://ar-dns.net/
# tantek saranix, except https://chat.indieweb.org/social/2017-11-29/1511967364739000
cdchapman joined the channel
# saranix that was re static publishing
# saranix nothing is wrong with it, it is just the only use case where it is logical, and is therefore this sort of tyranny of the minority in the spec -- in terms of, social, 500k+ users of diaspora+hubzilla don't do it that way, 99% of forum software, wiki software, etc. basically every single other use case that exists does not do static publishing and yet it is given the presumption
# aaronpk counterexample: https://micro.blog is a relatively large service based around static site generation
# saranix the "inbox" symantics are the presumption. even the name is problematic and myopic
# tantek that being said, we quickly discovered in the social WG that multiple perspectives were present that each had actual proof of concept experience in the wild, and rather than arbitrarily pick one, we decided to develop and iterate on a few, and that's where we ended up with a few different approaches that have some overlap
# saranix I still may publish an activitypub "translation"... not sure what to call it though
# saranix "implementers guide" has a ring to it - needs a subtitle or distinguisher to denote perspective though... hmm
# saranix lol I think MM would take exception to that :-P
# saranix I don't know if I'm representing just 1 perspective. As I said, I feel like there are many that are not represented.
# aaronpk UPDATE from yesterday's call, I just finished updated WebSub based on everything we discussed yesterday: https://w3c.github.io/websub/
# 
csarven saranix I'm not sure if I follow the issue or shortcoming of inbox that you are raising. Are you saying that it is not suitable for non-static resources? I'm also a bit lost on the conversation on inbox having its own inbox.. I mean, sure, that's permittet, because there is no constrain on what can have an inbox, but more importantly, if that's not a desirable thing to do, what's the problem? Does that open up the possibility to some catasostrophe?
# aaronpk http://htmlpurifier.org which is probably the most thorough sanitizer implementation in PHP does not allow <link> by default, so that's pretty strong evidence supporting your poitn
# saranix csarven: no, the argument was the opposite, if you "need" to have an inbox in order to deliver to a collection, and inbox is itself a collection, then logically inboxes are infinitely recursive. it's an error in logic in the spec is all.
# saranix luckily we figured out you don't need a separate inbox, or at least, no one has thought of a stumbling block yet. I will try implementing later in the week if I can
# saranix yeah... as to the use case that kicked this off https://www.w3.org/TR/activitystreams-vocabulary/#dfn-follow can be performed on any Object, it need not be a Person or their "outbox" or whatever implication
# Gargron let me just add that I think a video channel should be some form of Actor
# Gargron because usually you wanna subscribe to a channel
# saranix you need to have an actor to have signed content, that's for sure
# Gargron if your software has a concept of users who own channels, theres still no point following that user because maybe i dont wanna get *all* of their channels, you know?
# saranix of course everything could just be attributedTo their actual author, and not the channel, like whoever is publishing on the channel
# saranix and Follow can happen on any object, including a collection (channel)
# saranix but... if the channel doesn't have it's own actor, HTTPsigs won't work and you need LDsigs
# saranix right?
# Gargron the channel could totally simply be an actor? with own keys or whatever?
# Gargron you could even reuse keys of some underlying internal owner
# saranix I think it's easier to implement everything has it's own keys than to implement LDsigs :-P
# saranix but easier doesn't mean it's right.
# saranix I really wish LDsig wasn't so wonky
# Gargron i was recently thinking how the Move->Actor activity would be a use case for multiple ld-signatures
# Gargron basically if you wanna tell your followers "pls unfollow me and follow this actor instead" ideally you need permission from both old and new actor
# Gargron either you need to compose them somehow, e.g. Move signed by old actor, Announce->Move signed by new actor, and then you forward that Announce
# Gargron or you need to sign the Move using both actors
# saranix not exactly, new authorized pubkey can be published at old actor keyring
# saranix s/exactly/necessarily
# Gargron well
# Gargron you're saying "transfer the privkey to another server"
# Gargron and i say thats actually kinda limiting because it implies you can only migrate to a fresh account where you bring your key, or otherwise brick that new account's own existing stuff by replacing it
# Gargron it also means you either need to force ppl to download/upload a pem file or implement some kinda OAuth login thing to do it automatically which is Bothersome(tm)
# Gargron cwebber2: no that wouldnt require old server to be up since you can probably just check if the sig checks out with the cached key from old account
# saranix cwebber2: yeah the property on the actor object
# saranix Gargron: no not the private key, the old location only needs the new public key. The user places their public key from their new service on their old service out-of-channel (via UI)
# Gargron i have formed the belief that the sanest form of account migration is one where you dont try to literally merge accounts but instead simply formalize/automate the "pls follow me on new account" stuff
# saranix Gargron: if the user no longer has access to the old server, then their is no way around it, they are hosed
# saranix gargon: it's not a technical problem
# Gargron if you want to move *after* old server is gone i dont think thats possible in any of the methods
# Gargron in my method you would essentially send a one-time activity to your followers that would make them unfollow that account and follow the new one automatically
# saranix cwebber2: they need to take care that they don't lose access to their only access to their private key, that's not a technical problem. You can prevent ahead of time by always publishing a second public key (a mangement key if you will) to which the service provider does not have the private
# cwebber2 Gargron: one thing nolan and I talked about at TPAC was (and admittedly this would require that clients work to make this have reasonable UX) you actually sign your Actor object with a key you have on your device that your server *never* has, but that signature then gets attached to your profile's URI (and the profile can also sign that yes, I really am associated with this key, making it bidirectional)
# saranix cwebber2: that's what I just said, and in fact, is the only way to do it :-)
# Gargron im sorry but thats wishful thinking because nobody has a client app like that
# Gargron personal key management is an unsolved problem
# saranix doesn't have to be a client app
# Gargron well
# Gargron if you accept that you have to sign up on a phone
# Gargron and never lose the phone
# csarven "if you "need" to have an inbox in order to deliver to a collection, and inbox is itself a collection" -- those are two different use cases for me. delivery and distribution, right? so, inbox doesn't cover the latter. an implementation may purpose it to of course do distribution (like a mailing list)
# saranix A site can't claim that they allow migration away from their service even if the service goes down unless they provide a UI to make that statement truth.
# Gargron anyway im just waiting for someone with mastodon repo access to approve my PR that adds semi-compativbility with Video and Image objects
# Gargron another thingie i should fix before 2.1, and puckipedia knows about this, mastodon forwards the Delete activities a bit too much#
# Gargron e.g. sends it back even to the server it got it from and the origin
Loqi joined the channel
# saranix "key management is hard", we can just solve it like they did for email, oh wait...
# saranix >_<
# saranix I'm quantum surprised by this