2010/3/16 Blaine Cook <[email protected]> > On 16 March 2010 21:16, Melvin Carvalho <[email protected]> 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). >
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 >
