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

[cal]

On 09:52, Tue 30 Mar 10, Carlo von Loesch wrote:
> with a license that goes beyond the Affero GPL. It should be
> forbidden to run this software in virtual machines as the privacy
> of the users can no longer be secured. If you run the software on
> your own hardware server, even if it's in somebody else's rack,
> it is much harder to harvest. Maybe I'm just some five years early
> thinking about the dangers of VM computing, but that's traditionally
> my role hurrying ahead of time.

I'm not sure how could we check if such license is being applied, 
althought I see your point, and it is pretty scary...

Maybe we are abusing the term "federation" (meaning something in between
decentralized and distributed, depending on the day), and perhaps it is
a valid use case that different "federations" impose extra restrictions
for interconecting with their graph. We tend to draw a scenario where every 
site 
can talk with any other, but maybe *only maybe* some sites desire to
federate among equals and deny the access, let's say, to facebook users.
From my view, the problem with too much permissive gateways is that
they don't leave any incentives to part from the bigbrother jails. Do we 
still want to be viral?

> Concerning web interfaces as such.. I know well how powerful they
> have become and wouldn't be surprised if desktop interfaces were
> WebKit-based or similar. I would consider it a great move if we
> found a way to share HTML/JS or other web-oriented logic between a
> desktop and a web server implementation, so that the UI is
> fundamentally the same whether you run it locally or not.

Apart from the point about gnusocial itself forking some php 
codebase or not, I would agree with this approach. Never tested it, but 
projects like pyjamas seem promising at that respect (http://pyjs.org). 
Any experience with similar stuff?

> Concerning the protocol it still hurts to think it could be "web
> hook" based, but it could indeed be designed to be transport
> agnostic and run on several transports. I do however think it
> would be a good idea not to limit ourselves to round-robin
> distribution but to provide distribution trees. That means
> multicast structures on top of whatever is used.. be it HTTP
> or plain TCP/UDP. I can imagine designing a library for transport
> agnostic multicast, which allows distribution trees to use a
> hybrid of HTTP and plain networking.

I also  was missing some thoughts about the inverse travel: i.e., 
not only content publishing/distribution but also about information 
discovery and retrieval. (With public data or in a f2f darknet, the 
idea, no matter how complicated, can be the same).

One fancy thing about having data represented in RDF is how natural 
it results doing SPARQL queries against it. Not only raw data, but the
whole graph of concepts and relationships. SPARQL endpoints, again,
can be accessible from whatever transport you like, with any ACLs we are
capable of design (a la foaf+ssl, like taac does), and potentially could 
also route queries (there are some interesting algorithms about semantic 
query routing out there) to the endpoints they know are more likely to 
answer your query (of course  they can choose whether to reply your query 
or ignore it, depending on where you are in the  web of trust. And your 
SPARQL endpoint could be a webservice/daemon in the site/laptop of your 
choice). 
For sure we likely will be having slower query times, but I bet the quality 
of your social-filtered replies will be more optimal that the one-score-
for-all.

All this to say that searching in a distributed graph can
be the achilles heel of the system (we've seen that before), and that
I cannot imagine how else could we solve this in the classical GLAMP way, 
apart of waiting for any central crawler to come and index us. Surely my
problem is the one of only finding nails while holding a hammer :)

By the way, don't remember if has been mentioned before, but the approach 
of projects like http://smob.me  seem the right choice to me with
the goals in mind. ARC2 gives you the triplestore in php, frontend does
sparql... Savvy users can opt by deploying a more robust triplestore, sparql
endpoint can be encapsulated/translated to XMPP/PSYC, etc... freedom to 
imagine ;)

My doubt: Not sure if forking elgg/XXX and adapting the backend is gonna be 
more tedious that starting from scratch.

hail eris,
cal.

-- 
abra  su mente al dinero,
venda su alma al capital.

signature.asc
Description: Digital signature