Re: [Social-discuss] PHP-Based GNU Social structure

[Carlo von Loesch]

James Walker typeth:
| On Sun, Mar 28, 2010 at 3:41 PM, Henry Litwhiler <address@hidden> wrote:
| > On 3/28/10 3:35 PM, James Walker wrote:
| >> On Sun, Mar 28, 2010 at 3:28 PM, Henry Litwhiler<address@hidden>
| >>> On 3/28/10 3:21 PM, Matt Lee wrote:
| >>>> On 03/28/2010 02:57 PM, Henry Litwhiler wrote:
| >>
| >> Blaine mentioned our work earlier, but I would strongly encourage you
| >> to check out OStatus - http://ostatus.org/ . It already incorporates

PubSubHubbub uses a round-robin approach rather than multicast trees,
that is bad for popular feeds. Also it only "pings" which means more
traffic is generated by all recipients fetching the news in some overhead
file format, an approach that again would be like a slashdot if some
feed suddenly becomes very popular.

My notion of efficiency is rather some minimal data structure and method
containing exactly the new event, nothing else, delivered by steady TCP
lines or even UDP where suitable to all recipients, even if millions.

| >> both messaging as well as following/subscriptions. It's currently used
| >> by StatusNet (http://status.net/) - but is built on the same open
| >> protocol stack used by Google Buzz, Cliqset.com and others.

These techniques may be sufficient for a system that intends to
*publish* "status updates" but if you consider people may want to
massively chat on each update, and have these conversations encrypted
in such a way that only the intended recipients see it, not their ISPs,
then something leaner and more streamlined may be in order.

| >> I would strongly encourage you all to focus on adopting existing
| >> (preferably, rather than creating) open standards. True decentralized
| >> networking should be platform and language independent.

Unsuited open standards are frequently the highway to inefficiency.

| > I agree - we would probably be better off adopting something like OStatus,
| > rather than developing our own format.

If you compare the actual amount of data and complexity of TCP streams
on the wire of OStatus vs. XMPP vs. other things you will see HOW MUCH
this approach is far from efficient, and how much we could be doing
things better than has been done before. Latency too can be a factor.

| it's the only thing that really makes sense at the end of the day.
| (Note: I don't think you need to use the protocol that I personally am
| involved in- rather using something open / existing).

Even that isn't obviously true. Considering that we have a use case
roughly as intense as a chat technology, and the two leading free
software chat technologies, IRC and XMPP, both do not deliver
perfection, to use mild words. Additionally the future of privacy
requires cryptography on the personal device, leading away from the
web-based approach - unless we could do things using browser-based
client certificates like foaf+ssl does.

| Have a look at this list over the weekend - the people here can't even
| agree on which language and base architecture. Once one is selected,

It is pointless to talk of languages and architectures when we haven't
agreed on the true requirements yet, and haven't fully understood the
challenge before us.

| trying to pick a user interface and experience model that works across
| languages, cultures and fickle personal preference isn't going to
| work.
| 
| This is in large part why the twitters and facebooks of the world will
| never achieve full ubiquity.
| 
| *However* SMTP (warts and all) has come pretty darned close. Why ?
| It's simple, open and completely platform and interface agnostic.

That is another great and very logical point against the web-based
approach. Real client applications can provide an experience that
suits the personal device being used, possibly just providing access
to a slice of the social everything, that fits.

A mobile phone would only provide important status updates, while
a desktop client would even accept an mp3 that a musician friend is
sending to all of his peers. Web-based social interactions? Yes,
you can have that. It's like checking mail or doing IM via the web.
If we go for this, web-based social networks will be the way of the
past.

| If you're looking for decentralized networking - there are lots of
| players already in the game. Many of which are idealogically already
| aligned. I'd encourage you to contribute.

There are lots of players already aligned for EVERY architecture and
every school of thought. Each of us sits on some technology which
somehow does something social. If we want the truly best, we need to
consider the idea that something completely different from what we
have always done may be it.

So just because there is something that somehow works doesn't solve
the problem of agreeing on what we really want to achieve - if a hack
based on web hooks is enough, or if we want an infrastructure that
could even allow for social video streaming. Considering that the
difference in amount of work isn't all that huge, it's a pity to go
for the limited hack.

| >> Completely untrue - RSS&  Atom are document formats ... they can be
| >> pushed realtime (see above). See also PubSubHubbub -

Document formats are not what we need when we transmit each event
one by one. We just need a format for ONE event. Then deliver each of
those continously, in real-time.

| Hrm. Maybe spend a minute or two reading through pubsubhubbub. it's a
| "push" mechanism for RSS & Atom. the entries are *explicitly* sent to
| them.

Why think in terms of "entries" ?

| >>>> I think the UX would be similar to Facebook, but different in the ways
| >>>> we encourage communication.

Different for each language, each way of thinking, each personal device
and each usage requirement (true end-to-end privacy vs. worldwide
publishing)

-- 
___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___
___ xmpp:address@hidden ____ https://psyced.org/PSYC/ _____