Dear Social-discuss, don't look for László Török's original posting. He sent it to me in private by mistake. I'll quote it in full.
I said: | > My "URI" is psyc://psyced.org/~lynx although I don't consider myself a | > resource. If you want to know who my friends are you get a list of URIs | > in a list data structure. That's practical, because you don't have | > to extract it from some document. László Török typeth: | How does this exactly work? Is this a specialized function of the system? | (Not an expert on PSYC.) Currently it's in the reply to _request_description, that is how a profile is transferred within PSYC. Take https://psyced.org/~lynX for example - if you were my friend, you would see my phone number and my list of friends in there (the ones who agree to be shown to you - by configuring their trust and expose levels towards me). Actually you should be seeing https://psyced.org/~lynX?lang=en but by mistake it shows the fields in my language, not yours. Bug filed. Yes, the content could be formatted in a way ready for use by semantic web tools, but PSYC doesn't use those - it works with native data structures in the entire decentralized network. I don't even want my publicly accessible profile to be spidered and semanticized. I only want my friends to have that level of data quality. There's also a next generation approach to "requesting a profile:" In some future PSYC intends to notify all friends when you make a new friendship, and since that information is meant to be stored by every recipient (using the = syntax in the protocol), everyone already *has* the information in the morning when she woke up. There is no need to go and check out profiles. You already have the entire social graph on your laptop and perform computations on who might be able to help you with your maths homework or whatever. And it's not just some outdated cache. By definition of the protocol you always have the current graph with current phone numbers of your friends and whatever else they put in there, available on your hard disk to build amazing tools upon. Occasionally we will experience leaks, like Blaine Cook described them - some malware will be designed to harvest this information if you're a Windows user, some people will gateway their PSYC data into Facebook or sync it with public FOAF. But still that's less bad than having ALL information on public websites or within transparent virtual machinery (also known as commodity web hosting). It's the completeness of knowledge about social links of all of humanity which is a threat to political freedom, and as it stands some people are in the position of having access to the complete graphs of Internet's social networks, and a decentralized platform hosted on virtual machines would not change much about that. Maybe some good ISPs in some good countries would be safe havens, but how can you be sure? And would that still count as commodity hosting? What's worse, it's not okay to let the people decide about this - it doesn't solve the problem. The majority still believes they have nothing to hide, which is a terrible fallacy. We should not write code for the people who have nothing to hide. We should write code for everybody, even if they think they have nothing to hide. Did I just reply to a simple tech question with 6 paragraphs of rambling? Dude. | Btw you can do the same with SPARQL (you don't have to extract anything from | a document, you formulate your query and you get exactly what you asked for) | and actually much more. You can reuse the published linked data in ways the | publisher have never thought of and the system serving the data doesn't | necessarily have to programmed for this. (give me list of friends, etc.) Hmm I have mixed feelings about these query languages.. I've used them and I know you can formulate powerful things with them.. but I also noticed that if there's a chance you can keep your data rather flat and have your hierarchies in your naming strategy, you can access the data faster. The PSYC approach is, instead of processing a query language to extract data from a structured file, the data is stored in variables that have names that resemble a structured query. So when you need that data, accessing it takes close to zero processing power. Yes this approach is limited and I am willing to drop it if we hit the flexibility wall. ;) PSYC could just as well be adapted to additionally support RDF and SPARQL. | > PSYC isn't just a transport layer. It models multicast, subscriptions, | > trust and has extensible message structures. That's why you wouldn't | > typically do RDF on top of it if there are more powerful native ways | > to do things. But ways to regenerate RDF out of PSYC can be created. | I assume by saying powerful you mean faster? There are other measures of | being powerful: | expressivity(!), extensibility, ubiquity... Yes, I mean those kind of features, not just faster. PSYC has a semantically pretty rich syntax for a network protocol, but unlike SGML-derived languages it was designed with a programmer's pragmatic point of view. Easy to parse, binary capable, rapid to extract info from it... | > There once was a working group on "binary XML." It didn't come up with | > a format but it created a wishlist of things binary XML should be able | > to do. PSYC does a lot of that, so you can think of it as binary XML, | > too. | > | I can see the merits of a binary serialization, but it comes at a steep | price. You need quite a bit of tooling around it. So I'd avoid using it, Ironically, the most obvious feature expected from "binary XML," being encoded in binary, is what PSYC doesn't do. PSYC is a binary capable text protocol, like HTTP. But the other features people wanted to gain from "binary XML" is what PSYC delivers pretty well. PSYC vs "binary XML" is discussed on http://about.psyc.eu/Syntax (the "The W3C Feature Checklist" paragraph) | unless the lack of requirements on computing resources would dictate | otherwise. (I come from the embedded world, now a bit about the lower end | too...) The embedded world could use semantically rich protocols that are actually fast to parse and process, right? | I think it was not merely an accident that the web as we know it has been | built around text-based protocols. The web started out with a protocol that closed its socket after each file transfer operation, defeating many useful features of TCP sockets. TimBL is a great visionary concerning URIs and hyperlinks, but he had no clue about network programming when he invented the web. It took many years until HTTP/1.1 finally fixed that behaviour. Sometimes brilliant ideas have great success, no matter if the implementation is good or bad. Counter-theory: There is no big reason why Bittorrent has to be a binary protocol, yet it works like hell. So does DNS, except for the historic security weaknesses. -- ___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___ ___ xmpp:[email protected] ____ https://psyced.org/PSYC/ _____
