#social 2017-05-20

2017-05-20 UTC
#
astronouth7303 so, my opinion is that we pretty much need http signatures for S2S authentication
#
astronouth7303 i think user-level authentication will just provide a false sense of security. In s2s, the server can choose any of its users to be.
#
astronouth7303 and the keys a provider signs with need to be independently discoverable
#
sandro Hm, that's 4am here, but I'll try to join later.
#
saranix astronouth7303: that sounds like what we have now. I don't know what http signatures means though.
#
astronouth7303 saranix: it's an IETF-track spec for applying cryptographic signatures to HTTP requests/responses
#
saranix like a header?
#
astronouth7303 if the signing key is publically discoverable (DNS, well-known URL), then you can verify that the S2S request you're getting came from a provider, and you have proof it's the provider they say they are
#
saranix is the purpose to remove reliance on TLS server cert?
#
astronouth7303 no, it's to verify the requestor; TLS verifies the server
#
saranix oh. that would be convenient
#
astronouth7303 (reference: https://tools.ietf.org/html/draft-cavage-http-signatures-06 )
#
astronouth7303 so when another server submits an activity, or requests private data, or w/e, you _know_ what provider is making the request
#
saranix it's kind of ok for server-server stuff. great as a replacement to oauth for sure, but specifically for social, I see it as being mostly useful for the client. If only we could get browsers to send these. It would replace magic-auth like zot with something much cleaner. We've been waiting for some time for this.
#
astronouth7303 oh! i've been really concerned about S2S (because that's how you get federation), but yeah
#
astronouth7303 the trick with C2S signatures is key registration
#
saranix I think I might play with using this in an api I'm about to write. I hate oauth.
#
astronouth7303 i think oauth works pretty well for browser-based stuff
#
astronouth7303 but for native clients, it sucks
#
saranix funny thing is this draft is 1000 times simpler than everything similar that already exists. and not in a bad way. It's only as complicated as it needs to be, unlike the rest...
#
astronouth7303 the signatures draft? I haven't had a chance to look in to it in detail yet.
#
astronouth7303 my biggest concern is key discovery
#
saranix long term sure... for now patching together key discovery methods from the 5 or so biggest federations isn't that much of a chore
#
astronouth7303 you just have to make sure key discovery is independent of the request
#
saranix yeah that sucks
#
astronouth7303 it's something you can look up independently, given only a provider (host name?)
#
saranix webfinger? I know it's not perfect, but I'm not sure what you're getting at
#
astronouth7303 maybe? could be tied in to it? depends on how much webfinger is a thing
#
saranix well from a simple standpoint, zot uses zot-info@hostname (and also [system]@hostname), meanwhile diaspora uses something like host-info@hostname, IIRC
#
saranix can't remember why I started the sentence that way. ignore everything before the comma because I have no idea what it means :-)
#
saranix it's friggin hot here
#
astronouth7303 well, there could also be http[s]://hostname/.well-known/activity-pub.pem (or w/e)
#
saranix the whole .well-known thing is a very hastily hacked thing that needs to be revamped IMHO
#
astronouth7303 i mean, that's basically how robots.txt and favicon work
#
astronouth7303 i'd also be a fan of putting the key in a DNS TXT record (somehow)
#
saranix another junk drawer, but somehow preferrable. Actually SRV makes more sense to me
#
saranix or something new
#
saranix RSA
#
saranix dunno
#
astronouth7303 can't put a key in a SRV record?
#
sandro Have you seen webfist? It brilliantly leverages the key already in the DNS records for spam control
#
astronouth7303 also, good luck getting the IETF on board with another record type
#
saranix well the other problem with that is at least https has MITM protection, DNS does not
#
sandro astronouth7303, .well-known is a lot of things, but hastily hacked it is not. It was argued for many many many years, what to do about robots.txt and favicon.
#
astronouth7303 blames saranix for that comment
#
saranix yeah that was me, I stand by it though :-)
#
sandro oops, yes, sorry, that was saranix :-)
#
astronouth7303 hastily points fingers
#
astronouth7303 (maybe webfingers?)
#
saranix chortles
#
sandro I'll happily agree it *looks* hastily put together, but I remember people arguing about for years on end.
#
astronouth7303 i suspect there's a lot of pointless arguing at w3c
#
saranix well, perhaps it's the wrong characterization. I was trying to get at the arbitraryness. It doesn't seem reflective of inherent properties or any sort of decades of learned wisdom.
#
sandro yes, but perhaps less than most other places :-)
#
sandro yeah, everyone agrees .well-known is totally an ugly hack, they just couldn't come up with anything else that worked nearly as well.
#
saranix not saying I could do better than .well-known, it just feels like a hack to me
#
saranix yeah
#
sandro posts new swicg issue that's been preoccupying him today: https://github.com/swicg/general/issues/4
#
Loqi [sandhawke] #4 Forwarding
#
saranix you know what might make more sense? although equally unpracticle... adding a special field to the servers x509...
#
saranix hmm.. my protocol has something like this called "tombstoning". It isn't at the server level though, only the identity level. Server level would be good though. Just hadn't gotten that far...
#
saranix the way I handle it, currently, is just with HTTP. 301 Forwarding for a time period, then 410 Gone for another time period, after which point the ID becomes reusable.
#
saranix actually I refer to this as tombstone period, retirement period, and rebirth period
#
sandro Yeah, first cut 301 is fine. There are hard bits, though, like you need each post forwarded to the right place, and webfinger
#
sandro I think it's wrong, as I write there, to every turn off a URL that someone might come looking for in 10, 20, 30 years.
#
saranix it all comes down to who pays for 30 years of storage and retrieval... wrong? nah.
#
saranix it's up to the linker to make sure to follow redirects and keep their links accurate
#
sandro As I say, sometimes these links are in archival storage, or on paper, or in email.
#
saranix not as if the web is resilient to that without social
#
sandro And I think it's one line per user in an nginx file. Really, really tiny server. No storage needed, if done right.
#
saranix and any proper archive should still regularly cron to keep redirects up to date
#
sandro Well, twitter and facebook *are* remarkably stable in that regard. And we don't have to give that up.
#
saranix haha yeah right
#
Loqi ahaha
#
saranix I hope stupid useless evil crap like twitter and facebook aren't around in 30 years
#
saranix I sure as hell hope the dossier facebook collected on me without my permission is gone by then
#
sandro I have various bookmarks and notes of URLs. The earliest twitter one is from 2010 and still works. No matter what you think of Twitter, that's a really good thing for the web and the people who use it.
#
sandro https://twitter.com/fabien_gandon/status/13083071358 if you're curious
#
Loqi [@fabien_gandon] Linked Data Tables: publishing RDF using WYSIWYG HTML http://bit.ly/8Xvx1F Sandro Hawke @sandhawke #lod #www2010 #w3ctrack
#
saranix just threw up a little
#
saranix "good thing for the web" *retch*
#
saranix does that bit.ly link still work? I refuse to click on either twitter.com links or bit.ly links to check
#
sandro Yes, the bit.ly link was slow but still worked. It went to a domain that I have since stopped paying for. So Twitter and Bit.ly did the right thing, in terms of keeping the Web working (Cool URLs and all that), but I failed. :-)
#
astronouth7303 i don't think it's reasonable to keep per-object redirects for an entire provider
#
astronouth7303 (there's no guarantees the target provider uses the same URL scheme as you)
#
astronouth7303 and i think you're severely overestimating the amount of data even failed services have
#
saranix yeah. For my service, the user has an option: static url redirect (e.g. host.example/user/foo/anything redirects to newhost.example/home/foo), or, same path redir (from.example/foo/bar -> to.example/foo/bar), or, in some custom cases, I'll allow a regex. But I'm really nice to my customers. I wouldn't expect that to be mandatory for a spec. :-)
#
saranix and I don't guarantee that a specific post url won't end up with 404. If it's been deleted and I don't know the author anymore, I can't redirect tombstone.
#
aaronpk the IndieWebCamp Nürnberg livestream will begin shortly! https://indieweb.org/live
KevinMarks_ joined the channel
#
@danbri @robinberjon https://www.w3.org/TR/activitystreams-core/#example-3 is also somewhat related (twitter.com/_/status/865910518136963072)
KevinMarks and tcit joined the channel