#indiewebcamp 2011-08-01

2011-08-01 UTC
#
aaronpk alright! We got it talking between aaronparecki.com and brennanovak.com now!
#
aaronpk brennannovak.com*
#
brennannovak w00t!!!!!!
#
tantek congrats aaronpk and brennannovak!
brennannovak and tantek joined the channel
#
tantek aaronpk - sounds like you should add that Indieweb-messaging github to http://indiewebcamp.com/Projects :)
#
tantek so here's the question re: indieweb-messaging prove you are who you say you are -
#
tantek can OAuth 2.0 solve this problem for us?
tantek joined the channel
#
aaronpk edited /User:Aaronpk (+66) "/* projects */" (view diff)
#
aaronpk edited /Special:Log/upload () "uploaded a new version of "[[File:aaronpk.jpg]]"" (view diff)
#
aaronpk edited /User:Aaronpk (-36) "/* Aaron Parecki */" (view diff)
#
aaronpk edited /projects (+698) "/* experimental */ added info and links for IndieWeb Messaging" (view diff)
tantek joined the channel
#
aaronpk good evening tantek!
#
tantek good evening!
#
aaronpk I talked about this protocol with Kyle and Brian this evening a bit
#
aaronpk We were thinking about other ways to handle identification
#
aaronpk but didn't come up with anything really compelling
#
aaronpk OAuth 2 doesn't really help, since OAuth is more about granting access to an existing account, and there are always three parties involved
#
aaronpk proving who you say you are will ultimately always require contact with the person in question, so it becomes either 1) ask if they sent the message, or 2) use their public key to verify the signature of the message
#
aaronpk that was our conclusion
tantek joined the channel
#
aaronpk alright got a writeup http://aaronparecki.com/IndieWeb_Messaging
#
aaronpk brennannovak: ^^
#
tantek 1 sec bbiab
#
tantek oops
#
aaronpk cool well I'm pretty happy with the writeup and the live demo!
#
aaronpk not bad for a half day of hacking
#
tantek seriously - nicely done
#
aaronpk thanks!
#
aaronpk the post is supposed to be not overwhelming, so the reader might feel like they could implement it on their own site relatively easily, and not necessarily using the code I wrote
#
brennannovak very nice writeup aaronpk: great job!
#
aaronpk thanks brennan!
peck_lx and gazoombo joined the channel
#
singpolyma aaronpk: Reading http://aaronparecki.com/IndieWeb_Messaging. (1) If you use HTTP you should use Salmon (2) Why are you using HTTP?
spinnerin and quartzjer joined the channel
#
brennannovak oh this is a cute use of the GItHub API... nerd awards http://coderwall.com
quartzjer and tantek joined the channel
#
tantek singpolyma, re: Why are you using HTTP? A: Because Salmon is too complex/hard for anyone to get working?
#
tantek spec should proceed after implementations, not before
#
singpolyma tantek: uh... Salmon is also HTTP :)
#
singpolyma and it's basically just atompub with some discovery... so... not really that complex, but whatever
#
aaronpk singpolyma: are you saying that we should use message signatures instead of simple token verification?
#
tantek singpolyma, so why all the complexity/difficulty above "just use HTTP POST to the root domain"
#
tantek singpolyma - evidence of complexity is lack of implementations
#
tantek ergo, your assertion "not really that complex" is false.
#
singpolyma tantek: because POST to the root domain (ie: well-known URIs instead of discovery) has shown to be fragile in the past
#
tantek "shown to be fragile" - please provide URLs of implementation attempts
#
tantek I suspect such "fragility" was pre-mature attempts to generalize beyond the indiewebcase
#
singpolyma favicon.ico / robots.txt are the historical ones
#
tantek root != well-known URI
#
tantek root == what people refer to each other as/by
#
tantek e.g. I am tantek.com
#
tantek etc.
#
tantek directly tied to human notions of URL-based identity
#
singpolyma Ok, I'll accept that
#
tantek no /magic-path.xml etc.
#
tantek so no this is not the "well-known URIs" problem
#
singpolyma using raw POST, though, means that URL can't possible accept POST for any other purpose except this particular protocol
#
tantek what else is it using it for? plus, just use params (e.g. aaronpk's implementation already does this)
#
aaronpk singpolyma: that is true, however I haven't found any other code in the wild using POST to the root path
#
singpolyma Well, on my site I have used it for "trackback to main page" or alternately a way to get replies/comments in the past
#
aaronpk it can also be overloaded by recognizing the post body params and acting accordingly
#
singpolyma could use alternate verb or mime-type maybe. I'm not sure the body params are sufficiently unique to do that by themselves, but maybe they are
#
singpolyma also: salmon has been implemented. there's at least status.net, rstatus, cliqset, and a wordpress plugin
#
aaronpk mime-type could be viable, but I'm hesitant to make it much more difficult to implement than simple post body
#
singpolyma aaronpk: if the POST body were Atom instead, that would make it much more flexible / detectable
#
aaronpk oh no, not xml. then implementors have to import an xml parsing library instead of just reading post variables
#
singpolyma lol. anyway, my original argument was against HTTP (which I realise this community won't go for, but I feel I have to make it anyway)
#
singpolyma And in favour of something actually good at this. The historical example being SMTP
#
singpolyma The dialback thing is a seperate issue. It's "fine", but there are obviously problems with it :)
#
aaronpk I'm also interested in other protocols, especially SMTP (I have been known to abuse SMTP to do my bidding) but in reality, not everyone with a web page up has the ability to handle incoming SMTP traffic
#
singpolyma aaronpk: that sounds like a technical problem. technical problems are the easy part :)
#
aaronpk I disagree
#
singpolyma Really? I see technical problems solved all the time. In multiple years of discussions on this, though, most people haven't even *gotten* to the use cases or UI problems
#
singpolyma Things like "why do we want this" / "what is it for" / "what does it look like to use it"
#
aaronpk right, that's why we're starting from the other end, starting with implementation and UI
#
singpolyma really? because all that's on that wiki page is a protocol spec... an new one, that invents stuff
#
aaronpk I'm happy to listen if you can suggest a cleaner implementation that accomplishes the same goal with the same prerequisites
#
singpolyma So, the goal is a bit unclear. It seems to be "replace IM with HTTP"
#
aaronpk ok perhaps I should clarify the goal on the wiki page
#
singpolyma :)
#
aaronpk ok well that's a start http://aaronparecki.com/IndieWeb_Messaging#Goals
#
singpolyma aaronpk: ok, so what about those goals is not solved my hCard?
#
singpolyma s/my/by
#
Loqi singpolyma meant to say: aaronpk: ok, so what about those goals is not solved by hCard?
#
aaronpk an hCard pointing to an IM address or phone number?
#
aaronpk then you have to engage another communication channel and have infrastructure to send to the other medium
#
singpolyma well, that's all you've got here, it's just that you've invented a new communication channel for that other channel to be
#
singpolyma which I would be fine with if we didn't already have several standard ones and many more snowflakes like this :)
#
aaronpk not invented a new channel, since ultimately the message gets delivered over an existing channel. The method of delivery is left up to the recipient instead of the sender.
#
singpolyma aaronpk: but that's the case anyway :) it's just a new communication channel from the sender's perspective. and from a reply perspective
#
aaronpk i.e. if you want to send me a message, you shouldn't have to figure out if I'd prefer to get an SMS, Twitter DM, IM, or email at any given time of the day. I should decide how I get my messages.
#
singpolyma I get SMTP messages over XMPP all the time, etc. frontend != backend anyway
#
aaronpk but the point is identity. I don't feel that my phone number represents my identity. I'd rather not share it with people if I didn't need to. My URL is my identity so people should be able to contact me through it.
#
singpolyma which I why I suggested hCard
#
singpolyma get an SMTP (or other) address from URL, use that
#
aaronpk I'd rather not even expose other addresses tho, people should be able to use my URL exclusively
#
aaronpk also SMTP addresses at personal URLs look silly. aaron@aaronparecki.com? tantek@tantek.com?
#
singpolyma contact@, me@, fancy-protocol@
#
singpolyma I happen to use singpolyma@singpolyma.net because I like it. I don't have to
#
aaronpk I've gone through several, a@aaronparecki.com ap@aaronparecki.com me@aaronparecki.com _@aaronparecki.com (that one confuses lots of sites)
#
singpolyma I'm 99% sure SMTP allows singpolyma.net as an email address, but lots of stuff refuses that
#
singpolyma hmm, my mailserver seems to be rejecting that, so maybe no
#
singpolyma but the point is that humans shouldn't type that anyway. they should type my URL and their client should figure out my address from my hCard
#
aaronpk but what if you wanted a message delivered via SMS instead?
#
singpolyma then your server sends it to you via SMS...
#
singpolyma changing the sender protocol should not affect the recipient
#
singpolyma you still choose what you want there
#
aaronpk my point is that that is technically more difficult to implement
#
singpolyma because people are all on shared hosting without procmail?
#
aaronpk or heroku, or phpfog, yea
#
singpolyma could use POP-based script
#
singpolyma for those people
#
singpolyma which I realise is slightly more complex than inventing something brand new
#
aaronpk environments where they can easily add a script that handles HTTP post, but anything else is impossible or adds unnecessary cost
#
singpolyma So: switching gears. How do replies work in your proposed system?
#
aaronpk I suppose you could include an "in_reply_to" field and pass in the previous message id
#
aaronpk but really all you'd need is just to send a plain message back
#
singpolyma no, I mean in the UI
#
singpolyma since you're getting an XMPP, SMTP, or SMS message
#
singpolyma how do you reply?
#
aaronpk well you see the domain name of the sender, so you can just send a new message to them. If you wanted to be fancy you could write a new client that handled that better.
#
tantek singpolyma: re: salmon implementations - is there a wiki page that lists them and links to them (and their endpoints) or are you just making that up from memory?
#
singpolyma tantek: from memory. I can add something to indiewebcamp wiki if you like
#
tantek singpolyma: and regarding unnecessary invention - that part is my fault - I suggested to aaronpk that indieweb-messaging could/should be as simple as just issuing an HTTP POST to the root domain, and then some hand-waving IP vs DNS and whitelist/blacklist for domain authentication.
#
tantek singpolyma - that's part of my point, is there a salmon wiki?
#
tantek no longer believes in any standards efforts that don't have an active wiki.
#
singpolyma oh... there probably is. I could look
#
tantek no wiki = no community
#
tantek no community = dead standard
#
singpolyma http://code.google.com/p/salmon-protocol/wiki/SalmonLibraries << libraries (not all implementations, just libraries) on the Salmon wiki
#
singpolyma aaronpk: on replies: right, so you can just use this new protocol to send a message back to them. for which you need a new client of some kind. This is quickly sounding like yet another communications channel
tantek, quartzjer, peck_lx and MarkDilley joined the channel
#
tantek btw IndieWeb folks, here's a reference for the 2011-05-31 death of Friendster as a social network: http://www.nytimes.com/2011/04/27/technology/27friendster.html
tantek, spinnerin and spinnerin_ joined the channel