2011-07-31 UTC
# 00:00 aaronpk tantek: re: your indieweb DM idea, how would you envision that be implemented? A new <link rel="DM"> tag specifying the endpoint? # 00:01 tantek ideally there should be no explicit discovery markup needed # 00:01 tantek should just be able to follow a simple OAuth2 flow # 00:01 tantek well the sender should have to OAuth to the recipient in order to deliver it # 00:02 tantek and then inside that perhaps all it does is do an HTTP POST to the site URL itself gazoombo joined the channel
# 00:03 tantek (including OAuth auth tokens etc. so that the receiver knows who it is coming from) # 00:03 aaronpk hm, that seems fragile, I think it would need to be able to be delegated to at least a different URI # 00:03 tantek let's get it working for the indieweb case first # 00:04 tantek does wordpress handle HTTP POST requests to the root "/" ? # 00:04 aaronpk actually most frameworks these days do that (i.e. CodeIgniter and MediaWiki) # 00:06 aaronpk ok so if I want to send you a message, I'm going to make a POST request to tantek.com # 00:06 tantek makes sense right? total literal use of HTTP POST :) # 00:32 gazoombo drops in at an awesome point in this conversation and goes back to read the logs. # 01:02 gazoombo very resourceful... ;-) tantek, spinnerin, lmorchard, gazoombo and spinnerin_ joined the channel
tantek, brennannovak and gazoombo joined the channel
# 23:05 aaronpk tantek: I have a working prototype of IndieWeb Messaging! # 23:06 aaronpk I'm going to put the code on github and get brennan to install it since he's right here next to me # 23:07 aaronpk you're welcome to come by if you need a cool place to hack! # 23:07 tantek aww - would except just got settled in with @erinjo at Crema on 28th # 23:07 aaronpk ok i'll describe the flow, then I want to write a post about it # 23:10 aaronpk My server generates a unique message ID for this message and stores it locally, # 23:10 tantek right, indieweb local storage of sent messages # 23:11 tantek personal archive of all things you create - exactly # 23:11 aaronpk Your server recognizes the POST request and message ID and attempts to verify that aaronparecki.com really did originate the message, # 23:12 aaronpk if my server responds "confirmed", your server continues and delivers the message to you however you have it set up to do it # 23:12 tantek ok, that's a good first iteration, now what about the potential abuse for DoS? # 23:12 aaronpk this doesn't solve DoS or spam, but does confirm intent # 23:12 tantek e.g. zombie army sends out posts to tons of other servers claiming to be delivering a message from yahoo.com # 23:13 tantek then all those other servers immediately send the POST back to yahoo.com with the message_id param = DoS attack # 23:13 tantek basically, with a simple cleartext callback, you can cause the callback to occur to another server = DoS potential # 23:14 aaronpk right, but it was the simplest solution I could think of, I wanted to start from there and work forward # 23:14 aaronpk I think the next best may actually be a public/private key solution to sign the message, but that starts getting complicated fast # 23:16 tantek what about DNS lookup against the claimed from URL and seeing if it matches the IP of the sender? # 23:16 aaronpk That works most of the time, but in my case it would actually fail. # 23:16 tantek would that make for a simple 1 server with 1 IP workable solution? # 23:17 aaronpk My server has three external IP addresses so its default gateway is not aaronparecki.com's IP # 23:17 aaronpk but it would work if the server has only one external IP # 23:17 aaronpk it would also be insecure if there were multiple domains on the same IP # 23:20 tantek do your 3 outbound addresses have unique subdomains? # 23:22 aaronpk email solves this problem by delegating via MX records, and uses SPF to create a whitelist of other servers that are allowed to send mail on that domain's behalf # 23:27 tantek The problem here is trusting domains on behalf of other domains # 23:27 tantek solving this would also solve a store-and-forward scenario. # 23:27 tantek where you could pass a message to another server if the intended server was temporarily down, and have some agreement/policy on retry or drop within 24 hours or something # 23:27 aaronpk isn't the problem being able to prove you are who you say you are? # 23:28 tantek 1) with 1 shared IP across multiple untrusted domains, avoid message falsification # 23:29 tantek 2) with a domain that uses multiple IPs to send (each of which have their own domains) having a way to say, you can trust domain A on behalf of domain B # 23:30 aaronpk I feel like email has already solved #2 as well as store-and-forward # 23:30 aaronpk there are also some decent solutions to #1 with email, but it quickly gets complicated to implement # 23:32 tantek I think email got overly complicated because of the users at domains problem # 23:32 tantek so part of the goal here is to make it so that the protocol makes it too expensive to be worth being a spammer
aaronpk it probably should work wirh wordpress, since every request is actually routed through /index.php
gazoombo drops in at an awesome point in this conversation and goes back to read the logs.
Loqi [http://twitter.com/aaronpk] Turns out when you work under the #indieweb assumption that every person has their own domain, many problems become a lot easier to solve.