Disqus - Latest Comments for masonlee

Re: New Group Messaging Service Rivals BBM, GroupMe & Kik

Mason Lee — Sat, 08 Jan 2011 02:38:07 -0000

Hey, thanks for the link! I see the lawsuit is about the way in message read status is shared with the sending party. Someone should sue for scraping the address book. :)

Re: New Group Messaging Service Rivals BBM, GroupMe & Kik

Mason Lee — Fri, 07 Jan 2011 16:33:41 -0000

Beluga DOES scrape your address book and save it on their servers. They do this so they can ping you every time someone you know signs up.

Not sure where these companies derive their sense of decency, but it's nice to know that bad behavior like this results in consequences. Hadn't heard of the lawsuit against Kik.

Re: A social namespace (Scripting News)

Mason Lee — Wed, 11 Nov 2009 18:52:00 -0000

Just some technical clarification here on XML namespaces and prefixes, based on the w3c spec: http://www.w3.org/TR/REC-xml-names/ . Hope this is helpful.

In your linked OPML example, the namespace is "http://scripting.com/storie...". "xSocial" is what the document is using as a namespace prefix. Prefix choice actually doesn't matter. Once the xml is parsed, all elements are bound to a namespace according to their prefix, and the prefix is then essentially forgotten for most logical purposes (round-trip xml editing being a common exception). Equivalent XML could use the prefix "foo" instead, as long the document declared xmlns:foo="http://scripting.com/storie...".

In sum, XML developers should be careful not to make assumptions about the prefix string being any specific value, and you should probably be advertising the namespace value in this post instead of the prefix name. You can change the prefix a hundred times a day-- only the namespace need remain constant.

Re: HowTo: Open discussion on proposed changes

Mason Lee — Tue, 29 Sep 2009 22:20:04 -0000

What I believe you did recently was say that to do RssCloud over HTTP REST, the list mentioned in the original spec should be comma delimited. You're not changing the spec, you're defining a new HTTP REST interface for it. I hope this is a fair understanding. Sorry for the sloppy language which came across wrong.

The point I wanted to make (not all that great or anything): If it would help the error handling, perhaps instead of saying "use commas" for making a list in HTTP REST, one could say "make the list one item long" for HTTP REST so we can take advantage of existing HTTP error codes: 201 Created, 403 Forbidden.

Re: HowTo: Open discussion on proposed changes

Mason Lee — Tue, 29 Sep 2009 21:18:35 -0000

Thank you, Matthew! My simplification absolutely won't work because of this. Returning the challenge parameter as suggested above seems like the best solution then.

Google.com and yahoo.com respond to nonsense POST requests with what seems the appropriate 405 status, but now that I'm hunting around, I find some not-so-dumb people returning 200, namely www.w3.org! Not my reading of the http spec, but oh well. :)

Re: HowTo: Open discussion on proposed changes

Mason Lee — Tue, 29 Sep 2009 17:50:39 -0000

If I recall correctly, Dave added the multiple URL subscription interpretation to the RSS spec only recently, where the spec was somewhat ambiguous. I agree that requiring one at a time makes the necessary error handling much easier. Otherwise someone might need to define the schema for a more complex response, like "A worked, B worked, C failed."

@cshotton, to your earlier point, I agree that a cloud hub server should probably not accept subscription requests for feeds it does not service. Good looking out.

Re: HowTo: Open discussion on proposed changes

Mason Lee — Tue, 29 Sep 2009 17:44:13 -0000

The domain parameter seems good.

Here is an alternative for the "challenge" parameter proposal, sharing the same goal to prevent attackers from signing you up for pings you don't want.

Rather than making a special challenge request, it might suffice to respect the relevant HTTP codes "200 Success" and "403 Forbidden" on every ping. If a subscriber does not want a ping, it could return 403, and the hub could drop then drop subscription.

For completeness' sake, hubs should also drop subscriptions for any non- 200 responses from "subscribers" who have never responded with a 200 before (e.g. 404 or 500), because in this case it would seem to indicate that the hub has started pinging something that doesn't accept pings.

By this scheme, we have no extra parameters and no extra steps in the protocol. The definition of HTTP 200 and HTTP 403 status codes can be found here. http://www.w3.org/Protocols...

Wondering if people think this is sufficient, or too much of a shortcut.

Cheers,
Mason

Re: I need a Domain Name Server with a REST interface (Scripting News)

Mason Lee — Thu, 17 Sep 2009 21:55:12 -0000

For the sake of completeness, here are some problems for using DNS as a generalized service registry. They may or may not affect the 140 char loosely coupled network ("Loose.ly").

1. The DNS cache can be slow to propagate, meaning there's an indeterminate lag between modifying a service endpoint (e.g. a feed address) and being able to use it fully. The best case for DNS NAPTR records is probably a 1-5 minutes lag, but it's ultimately up to each ISP's nameserver to decide how they want to setup their cache. The shorter the TTL, the less caching you get.

2. Javascript in the browser cannot make the socket connection to do a DNS lookup. Javascript widgets will need to contact some server running an HTTP service that bridges to a DNS lookup. And of course, an HTTP service is what most developers today will want to contact in the first place, Andy's fair points above notwithstanding.

3. Lastly, a general point which probably does not affect Loose.ly's casual use case: DNS is vulnerable to easy spoofing attacks and so cannot be used for looking up some other types of service endpoints, such as OpenID's single-sign-on delegation, or OAuth's authentication endpoints, or a person's public keys for digital signatures.

Just wanted to get that on the record. None of this is to say it can't work. Obviously DNS sure is clean and simple :)

Re: I need a Domain Name Server with a REST interface (Scripting News)

Mason Lee — Thu, 17 Sep 2009 01:39:44 -0000

By the same token that developers want to use HTTP POST to register their feed, won't developers want to use HTTP GET to resolve the names to feeds?

Re: HowTo: Proposed change 9/13/09

Mason Lee — Sun, 13 Sep 2009 16:27:28 -0000

I'd support that.

Step 5 could use some clarification. Seems to me there are a few possible approaches. I'd like to propose one:

A cloud hub server, when making REST pings must listen for HTTP 403 "Forbidden" response to a ping, and if received must drop that ping subscription.

HTTP 403 defined: http://www.w3.org/Protocols...

If adopted, this could mean that no separate verification request is required-- each ping is capable of being meaningfully rejected as undesirable.

Re: rssCloud meetup at UC Berkeley, Sept 9 (Scripting News)

Mason Lee — Wed, 02 Sep 2009 21:03:40 -0000

I plan to be there and am looking forward to meeting everyone.

I cross-posted this event to the DiSo google group: http://diso-project.org

Re: RSS is how the news flows (Scripting News)

Mason Lee — Wed, 26 Aug 2009 16:57:48 -0000

"Most are at odds with that with which they most constantly associate -- the account which governs the universe -- and what they meet with every day seems foreign to them." --Heraclitus (DK B72)

Re: How to fix URL-shorteners, part II (Scripting News)

Mason Lee — Tue, 25 Aug 2009 23:59:12 -0000

An improvement for use in Twitter for sure. You're no longer dependent on a third-party, and for the rest of us, your redirects are simple files that can be mirrored by archivists for when c.oy.ly goes the way of the dodo. (Does the bucket have a full public index?)

If I may ask: You've suggested that Twitter.com should include full links in their feeds, rather than pack everything into the 140 chars. If they did that, would you stop using c.oy.ly, or will you find too much value in this new click stats architecture?

I like the idea of public click stats. I'm glad you make your Top-40 report public.

Re: My #blogpostfriday post (Scripting News)

Mason Lee — Fri, 21 Aug 2009 22:50:13 -0000

Hope you get better soon, Dave. Need you to bad hair us.

My other comment is a post: "Is the web sticky enough?" http://masonlee.org/?p=91

Re: My #blogpostfriday post (Scripting News)

Mason Lee — Fri, 21 Aug 2009 22:48:22 -0000

Hope you get better soon, Dave. Need you to bad hair us.

My other comment is a post: "Is the web sticky enough?" http://masonlee.org/?p=91

Re: Custom browser for Facebook (Scripting News)

Mason Lee — Thu, 13 Aug 2009 19:11:03 -0000

Add Linux a la "Chrome OS" for a "Facebook OS" that runs directly on personal devices?

Re: Nietzsche Had An iPhone: 25,000 Views In A Day For Nietzsche Street Trivia

Mason Lee — Tue, 11 Aug 2009 02:23:43 -0000

You were kind enough not to mention that Trekkie crashed and completely erased Nietzsche's iPhone while trying to install an ad hoc beta build of Borange. But truth be known, that's how Nietzsche lost his contacts.

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Mon, 10 Aug 2009 22:54:06 -0000

Thanks for the clarification-- that's pretty smart.

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Mon, 10 Aug 2009 22:19:50 -0000

Since there's no standard for the strings chosen for XML prefixes (i.e. "fb" can be "twitter.com"), clients would need to come up with their own method for inputting and displaying the actual service URI. Is "t:" Tumbler or Twitter? There are many ways software can address this, for example, by using autocompletion when typing and showing service favicons when resolving.

However, once the significant aid of software is required, wouldn't the preferred solution be in having the client app automatically create and display usernames as hyperlinks? (e.g. [a href="http://blogs.foo/ username.twts "] @username [/a]) I'm not sure what introducing XML namespaces buys us.

Furthermore, while the namespace approach works for identifying a user in an existing namespace, when taken alone we are still lacking a method for finding the RSS feed for the user, which was the original motivation for this discussion. All identity providers referenced by the prefixes would need to implement some directory system such that client applications could reasonably implement "findRssUrl(namespace, username))". While "#{namspace}/#{username}.rss" may be one common result, it's not standard.

I keep falling back in my mind to having client apps just create and display hyperlinks to users in whatever way they prefer, as we do in blogging today. Apps could enhance this process with auto-completions from a local or shared address book, like most email apps do with the To: field. On the receiving end, if your client sees a URL that's in your address book, it shows your version of that person's name.

If that's not good enough, though, the best solutions for getting URLs from shortnames I've seen here so far are:

1. Domain-looking strings ("username.tel") one can attempt to resolve to a DNS record (record name and format TBD), as with Telnic.
2. I-name looking strings ("=username") one can attempt to resolve to an XRDS service (service name and format TBD), as with OpenID.
3. Email looking strings ("person@foo.com") one can attempt to resolve to an XRDS service (TBD) via the Web Finger code that Brett Slatkin links to below, http://code.google.com/p/we.... Doesn't look like Web Finger is ready yet, but seems killer from the surface.

None are mutually exclusive. Not sure where this gets us.

One more thought, though- if any of these links or services could resolve to a URL that ends in some new suffix, like "twt", we could recognize it as a 140 char stream right off the bat, and load it into our 140 new char RSS client, supposing they will exist. Are there better ways to do that?

=masonlee

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Fri, 07 Aug 2009 21:13:34 -0000

I can appreciate that, Dave. I'll be the first to admit I don't know how to build this in a way that will make it successful. There is a difference between technical workings and mass adoption workings, and I don't profess to be a master of either. That's why I'm here trying to learn and help where and if I can.

And, you're right, my stated problem #3 is not at all a problem for your Twitter URL override suggestion. It's i-names' problem, if anyone's.

I-names aside, the "@" syntax on the net is context sensitive. It's sort of like Kevin Marks mentions below regarding email resolution--go to the local domain. You'll see "@" in wordpress replies and in IRC chats alike, and they don't mean Twitter.com. This is the point I was trying to make.

Sorry if my idealism goes haywire-- I'm excited by all this stuff.

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Fri, 07 Aug 2009 19:00:00 -0000

Dang, my URLS were truncated.

Try THESE in your terminal, but removing the space btwn "http:" and "/", and you'll see the xrd.

curl http: //xri.net/=masonlee/blog/rss?...

Similarly, if you want to the url to skype chat me, do this:

curl http: //xri.net/=masonlee/skype/cha...

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Fri, 07 Aug 2009 18:48:12 -0000

Hey Dave, my thoughts on this are pretty obvious, but I'll share them nonetheless:

Five problems:

1. As a Twitter user, I don't want to use my Twitter URL field to point to my 140 char feed. I want it to point to my webpage so people can learn more about me. You're cheating me out of a useful field.
2. If you go with the idea that the open web should accept that "@" always points to Twitter Inc by convention--to be implemented by all client readers--you hand Twitter Inc a significant key to internet identity.
3. You create a problem for the i-name namespace, which also uses "@", and which is arguably more philosophically aligned with the open web.
4. You re-enforce the use of Twitter Inc and constantly remind everyone how much better the user experience on a centralized system is.
5. You can only register one url with these identities. You can't use the same name to lookup other information, like a public key, a full length blog, a skype address, etc.

Four benefits:

1. Easy for developers-- nothing has to be built.
2. Easy for users who are willing to give up their Twitter URL field.
3. Maintains the "@" namespace across Twitter and this new thing (Good for Twitter inc shareholders and for riding the hype wave).
4. *Necessarily* advertises this new 140 char RSS thing on Twitter. Bwahhaha!

It's a *bloody* brilliant hack, Dave, which I admire. But I have to say, it makes me extremely uncomfortable. Not that my opinion matters so much, but I'm not sure I could get behind encouraging people to use Twitter Inc for internet identity without more information about what additional identity services they plan to provide, and how they plan to separate their private money-making concerns from the public service of providing deep and evolving internet identity technology.

Best regards,
Mason

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Fri, 07 Aug 2009 17:58:38 -0000

Hi henri.tel-- .tel is definitely something to consider, and it really illustrates Dave's idea for using DNS directly. Do you know how much traction .tel is getting in the identity community? My main reservation against this solution is that with the coming onslaught of new gTLDs (ICANNs crazy plan for next year), ".tel" is going to get lost in the shuffle unless they have some real inertia somewhere. The thing about .tel is that there is no reason to prefer .tel to, say, .org for looking up these DNS records that point to your blog. This means that our short simple conversational user names would need to have a .xxx at the end. I'm not sure if that works. What does scripting.com think? How about you masonlee.org? Hmmm, yeah.

I do, on the other hand, like that it's just plain DNS! XRIs (I-Names) have some neat technical, benefits, but so far they are just just OASIS and OpenID approved and not yet W3C approved. Here's the W3C's statement rejecting XRIs and OASIS's response: http://wiki.oasis-open.org/... It's worth noting, however, that the W3C was *not* looking for a twitter short name replacement, which is the main attraction of i-names for me.)

Kind regards,
masonlee.org

;)

Re: Trading one centralized net for another? (Scripting News)

Mason Lee — Fri, 07 Aug 2009 16:42:57 -0000

It's hard to cost zero, and I don't think that's a fair requirement. Twitter is charging $0 because the want to monetize the firehose. Who pays the legal fees when Litigious, Inc sues our centralized name registrar non-profit for giving out their trademark "Litigious" as a shortname to some user? Or just the administrative costs of doing the registrations and running the servers?

There are free i-names here: http://freexri.com You basically piggy back off the business i-name @id, with @id*yourname. They are just giving them away. At any rate, your own i-name registration costs less than a second-level DNS record, which was one of the options Dave suggested yesterday.

So... how do i-names work? Damned good question! I can't really answer that here, but here is the developer resources page: http://dev.inames.net/wiki/...
Here is the XRI resolution spec that I'm currently not having fun reading: http://docs.oasis-open.org/...

And, here is my preliminary proof of concept for using I-Names and XRDS (the service discovery xml) to resolve a shortname to a URL for a service:

My i-name is =masonlee

I have the ability to assign arbitrary service descriptions to it. I decided to use "blog/rss" as the path to my blog service. There might actually already be a standard path we should use instead of this "(+blog)?", but forget that for now.

Now let's say we want to get the "blog/rss" for "=masonlee". The easiest way, right now, is through an HTTP call to xri.net, requesting the XRDS for my i-name that service name. There are more elaborate and decentralized ways to do XRI lookups, much like DNS (which I think Dave rightly reference as the model we're looking for) but let's ignore these for now and use the shortcut. (By the way all this is what is also required of OpenID 2.0, because i-names have to resolve to OpenID providers. As mterenzio says, you can use an i-name as an OpenID 2.0 login.)

Try this right now in your terminal:

curl http://xri.net/=masonlee/bl...

Similarly, if you want to the url to skype chat me, do this:

curl http://xri.net/=masonlee/sk...

I registered my I-Name at http://fullxri.com and set up both these service pointers there with their online tools (My I-Names -> Advanced -> New Service). I'll post a walk-through on how to set up the services a bit later. Fullxri.com doesn't have *nearly* the UI I would envision for setting up the pointer to your blog, but I think that could be overcome. There are other i-brokers, and we could even set up our own i-name i-broker that had a wizard just to get the rssCloud feed URLs into people's i-name XRDS.

Pretty neat, in my humble opinion.

=masonlee

p.s. One (of many?) remaining problems: The I-Name "@" business namespace conflicts with Twitter's ad hoc namespace convention. "=" i-names are the person namespace. Damn you, Twitter! :)

Re: Another brick in the cloud (Scripting News)

Mason Lee — Thu, 06 Aug 2009 19:56:28 -0000

Since neither of us ultimately want to see OpenID URLs in tweets because they are too long (see http://masonlee.wordpress.c..., then we need a centralized registrar for the short names. XRI foundation and I-Names exists for this already.

My suggestion for using OpenID urls above is just a compatible (and free) intermediate solution, proving that Yadis works for this. Yadis and XRDS is invisible to the end user.

Ultimately we'd set up an I-Names broker that lets you register an I-Name and specify your rssCloud. Advantage of this approach is that other people could also provide the same service-- it's not re-inventing the wheel.

What part about it don't you like? For me, it's the price of I-Names.