#indiewebcamp 2011-07-31

2011-07-31 UTC
#
aaronpk
tantek: re: your indieweb DM idea, how would you envision that be implemented? A new <link rel="DM"> tag specifying the endpoint?
#
tantek
ideally there should be no explicit discovery markup needed
#
tantek
should just be able to follow a simple OAuth2 flow
#
aaronpk
so a well-known URI?
#
tantek
well the sender should have to OAuth to the recipient in order to deliver it
#
tantek
and then inside that perhaps all it does is do an HTTP POST to the site URL itself
gazoombo joined the channel
#
tantek
(including OAuth auth tokens etc. so that the receiver knows who it is coming from)
#
tantek
I don't think we need anything more
#
tantek
zero discovery
#
aaronpk
hm, that seems fragile, I think it would need to be able to be delegated to at least a different URI
#
tantek
not for the indieweb case ;)
#
aaronpk
can that be hacked into wordpress somehow?
#
tantek
let's get it working for the indieweb case first
#
tantek
and then we can worry about other setups
#
aaronpk
ok sure
#
tantek
does wordpress handle HTTP POST requests to the root "/" ?
#
tantek
that's the key - whatever hooks into that
#
tantek
perhaps .htaccess etc.
#
aaronpk
it probably should work wirh wordpress, since every request is actually routed through /index.php
#
aaronpk
actually most frameworks these days do that (i.e. CodeIgniter and MediaWiki)
#
aaronpk
ok so if I want to send you a message, I'm going to make a POST request to tantek.com
#
tantek
makes sense right? total literal use of HTTP POST :)
#
aaronpk
I'm going to include text=hello&token=1234567890
#
aaronpk
so I need a token
#
aaronpk
in order to get a token, what do I do?
#
aaronpk
RelMeAuth?
#
gazoombo
drops in at an awesome point in this conversation and goes back to read the logs.
#
gazoombo
very resourceful... ;-)
tantek, spinnerin, lmorchard, gazoombo and spinnerin_ joined the channel
#
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.
tantek, brennannovak and gazoombo joined the channel
#
aaronpk
tantek: I have a working prototype of IndieWeb Messaging!
#
tantek
whoa!
#
tantek
between which two sites?
#
aaronpk
right now, myself and myself
#
tantek
sweet!
#
aaronpk
I'm going to put the code on github and get brennan to install it since he's right here next to me
#
tantek
describe the protocol flow
#
tantek
you're both at PIE?
#
aaronpk
you're welcome to come by if you need a cool place to hack!
#
tantek
aww - would except just got settled in with @erinjo at Crema on 28th
#
aaronpk
ah cool
#
aaronpk
ok i'll describe the flow, then I want to write a post about it
#
aaronpk
I start out by logging in to my server, and go to the "new message" form: http://aaron.pk/snip/2011-07-31_1609.png
#
aaronpk
I enter tantek.com and my message and hit "send"
#
aaronpk
My server generates a unique message ID for this message and stores it locally,
#
tantek
right, indieweb local storage of sent messages
#
aaronpk
then it makes a POST request to http://tantek.com/ with this body: from:aaronparecki.com&text=hello&message_id=1234567890
#
tantek
personal archive of all things you create - exactly
#
aaronpk
Your server recognizes the POST request and message ID and attempts to verify that aaronparecki.com really did originate the message,
#
aaronpk
it does this by sending a POST back to http://aaronparecki.com/ with the message_id parameter, and my server responts "confirmed" or "denied"
#
aaronpk
if my server responds "confirmed", your server continues and delivers the message to you however you have it set up to do it
#
tantek
ok, that's a good first iteration, now what about the potential abuse for DoS?
#
aaronpk
this doesn't solve DoS or spam, but does confirm intent
#
tantek
e.g. zombie army sends out posts to tons of other servers claiming to be delivering a message from yahoo.com
#
tantek
then all those other servers immediately send the POST back to yahoo.com with the message_id param = DoS attack
#
tantek
basically, with a simple cleartext callback, you can cause the callback to occur to another server = DoS potential
#
aaronpk
right, but it was the simplest solution I could think of, I wanted to start from there and work forward
#
tantek
makes sense
#
aaronpk
I think the next best may actually be a public/private key solution to sign the message, but that starts getting complicated fast
#
tantek
sure - PKI
#
tantek
what about DNS lookup against the claimed from URL and seeing if it matches the IP of the sender?
#
aaronpk
That works most of the time, but in my case it would actually fail.
#
tantek
would that make for a simple 1 server with 1 IP workable solution?
#
aaronpk
My server has three external IP addresses so its default gateway is not aaronparecki.com's IP
#
aaronpk
but it would work if the server has only one external IP
#
aaronpk
it would also be insecure if there were multiple domains on the same IP
#
tantek
well, spoofable in those situations
#
tantek
which is common in shared hosting setups
#
tantek
(I have that myself)
#
tantek
do your 3 outbound addresses have unique subdomains?
#
aaronpk
they are unique domains, not just subdomains
#
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
#
tantek
I feel like rel-me could help here
#
aaronpk
can you elaborate?
#
tantek
The problem here is trusting domains on behalf of other domains
#
tantek
solving this would also solve a store-and-forward scenario.
#
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
#
aaronpk
isn't the problem being able to prove you are who you say you are?
#
tantek
two problems
#
tantek
1) with 1 shared IP across multiple untrusted domains, avoid message falsification
#
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
#
tantek
2) might be solvable with rel-me
#
tantek
1) is more challenging
#
aaronpk
I feel like email has already solved #2 as well as store-and-forward
#
aaronpk
there are also some decent solutions to #1 with email, but it quickly gets complicated to implement
#
tantek
I think email got overly complicated because of the users at domains problem
#
tantek
and it's obviously subject to spam
#
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
#
tantek
with from-domain verification