2010/3/16 Blaine Cook
<address@hidden>
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.
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).
More a philosophy than a specific proposal. GNU works on the principle of "free as in freedom", of which, a natural consequence, is that the user will expect to have fine grained control over their data, their connections and their messaging. The GNU brand has time and again lived up to this reputation, and I think is generally trusted. And of course, with AGPL, if someone finds a flaw or something they dont like, they can change it for the good of the wider community.
> 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.
FOAF has had a few new features in the last couple few years.
Apart from moving to align the spec to something more modern such as (portable contacts / opensocial). It's benefitted from a query language (SPARQL), ability to embed in HTML (RDFa) rather than the relatively verbose RDF/XML, single signon is a new ability with FOAF+SSL (even with fallback to OpenID possible), access control is starting to take shape which was really missing from the equation previously, and with sparql 1.1 coming this year it will have a cross server update ability which will transform it from generally static to read/write. Meanwhile the linked data cloud has been coming steadily along with FOAF at the center, the tools in general are more mature.
So there was buzz about FOAF in 2004, and in general it didnt live up to expectations, it's a lot further along now. Still now perfect, and lots more work to be done,,as you rightly point out message protocols are a shortcoming, but good people are working on them, and we're much further than we were. FOAF simplicity allows it to use HTTP/Sparql Update or even WebSocket to a reasonable effect, while of course being compatible with most existing messaging layers. So I think it' s in a usable state now where people can start to see the power, but there's only better to come.
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 think the idea is that a free stack mandates that the person running the code should be able to determine how many users they want to support, with even as low as one user, running the software, controlling their data and yet being able to make connections with other nodes. If architecture well enough it should be able to run on a web server, a personal server, an app, a browser, or a mobile device.
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