Re: [Social-discuss] Protocol / Design Considerations.

[Blaine Cook]

On 16 March 2010 21:16, Melvin Carvalho <address@hidden> wrote:
>
>> HTTP URLs don't work as addresses *for people*.
>
> Not sure on this one.  Something that twitter does well is addressable
> profiles.

Twitter addressable profiles aren't URLs; (statistically) no-one
thinks of Twitter profiles as URLs, and Twitter very much would prefer
if they didn't. Instead, Twitter uses identifiers that aren't even
URIs - @name. Those identifiers aren't decentralized, they're not
resolvable outside of the Twitter context, and most importantly they
make sense to people.

That said, they only sort-of make sense to people. Anyone with a
common name will readily attest that they frequently get @name replies
that are for other people with the same name. This probably has more
to do with the relatively infrequent use of Twitter for private
communication, and thus the infrequent dire consequences of using the
incorrect address.

> Partially agree.  Linked data is farily standardized now as a global format,
> verious APIs should be supported on merit, just as drivers are used in
> gnu/linux to talk to various hardware specifications.  Every API supported
> will add something more to GNU Social.  But API's themselves generally hide
> data.

Agreed, though I would caution that at this early stage, data is of
secondary importance. What I'm arguing for at this point is to get the
transport protocol and addressing protocols right. Email, phone, and
postal systems are all just methods for transmitting arbitrary data.
The data only matters to the recipients; the delivery agent only cares
about the envelope. We would do well to replicate this.

For early prototypes, complex data is probably overkill. Virtually
every social network emits Atom, which is why I present it as an early
target for application-level support (and, in the case of PSHB,
gateway support). Support for Linked Data, Activity Streams, and so
on, will emerge as integration work requires it, but just as SMTP and
HTTP servers don't "understand" MIME or HTML, I expect that the same
will be true of this new breed of social data gateways.

> Agree.  It's a tricky problem, one that will hopefully give GNU Social an
> Edge.

Are there proposals on the table? Is there a reason to suggest that
GNU Social would have an edge over any other suite of protocols? My
ideal is that we all gain an edge over proprietary networks by working
together. I'd hate to see a world where a plethora of semi-proprietary
"open" protocols emerge, allowing proprietary networks to evolve ahead
of us (c.f., TCP versus alternatives is a success story because people
agreed to use TCP in the interests of interoperability. Likewise SMTP
versus UUCP/CompuServ/AOL/etc).

> Was once of a similar opinion to this, but now FOAF is ready for prime time.
> IMHO.

What's changed? Basically my view is that so long as FOAF is about
describing relationships rather than enabling message exchanges, it's
not suitable as the basis for these networks.

I look at it this way: application developers are going to store my
social network no matter what I do, and the social network that I
build on Twitter is very different from one I'd build on Ravelry or
Flickr. The nature of many networks means that I don't want to publish
my relationship details anywhere publicly (beyond the fact that
publishing your network details is somewhat creepy); as such, it's
easier to do it on the site that I use to interact with my extended
(Topic/Theme+Social Sphere) contextual network. Or, FOAF puts the cart
squarely before the horse.

> Tho I think GNU social will be more that just a website with distributed
> features (for which the stack you describe is quite well suited), more a
> distributed network with website like features, but also global reach.  In
> short, not like anything that has come before, yet with many of the
> strengths.

How so? I'm not sure I understand how a distributed network would
exist *outside* of websites. Certainly, non-web aspects may be
incorporated (e.g., IM or SMS integration), though I'd argue that
we're moving *more* towards an HTTP and HTML-centric world, not less.
"HTML5 Apps" for mobile devices[1] is a great new frontier in that
sense, and one that will only further the HTML-ness of social
networks.

I tend to take the approach of not trying to invent anything new
(indeed, Twitter was just a re-hashing of many ideas that had come
before, despite "feeling" new) because "new" rarely succeeds. Human
history is one of incrementalism, to great success.

b.

[1] http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html