Am 01.11.2013 03:03, schrieb carlo von lynX: > Goodness, I overlooked this message... > > Did I really not respond to this? > Or did I just fail to answer to the mailing list?
I haven't seen an answer until today. S* happens, thanks anyway. > On Mon, Oct 07, 2013 at 01:39:05PM +0200, J?rg F. Wittenberger wrote: >> I too got some questions about secu-share/psyc I always >> wanted to ask. >> >> What I'm looking for is a replacement for some working code. >> (Yeah, I know never touch a running system... But I view code >> as a duty, not an asset. Whatever I can reuse would be a win.) >> >> Could I do the following reasonably using PSC? >> >> The code in question would be the communication protocol used for BALL. >> http://ball.askemos.org/ > > Woah. This is complex. > I am totally not getting what you are doing there. I see. I never really understood how it comes. The idea is actually pretty simple. To those who understand German, you might enjoy the video "Askemos - ethische Cloud" of a talk I gave on the subject on the last local CCC here http://datenspuren.de/2013/ (you need to scroll, all talks are presented at a single page there). Basically the idea is to take the servers out of the architecture of the web. Hardly possible I hear you saying? What's going to serve the content? The caches! Just have them conspire to pretent the server exists. Everything will look fine from the browsers point of view. (BTW: the concept is not bound to be "web only" but that's probably the best way to explain it.) The whole idea is *very much* inspired by the way human societies came to understand the concept of "truth as perceived by their legal systems (or the public)" (which *may* be a very different thing than truth as perceived by individuals). That is: whatever the topic, there are several individuals informed about it - or else it did not happen (to the legal system!) - and whatever most of the concerned believe to be true is taken to be true. As such it certainly counts as some kind of social network software, doesn't it? Unfortunately it seems to be true: those web sites show a clear lack of didactic expertise on the writers part. Question welcome to improve the situation. >> (((BALL is in a way yet another "social network software", albeit >> we seriously claim it being based on strange, 300 years old >> ideas like democratic societies - much in contrast to the cloud-hosted >> networks under control of their respective parent companies. >> It also does not enforce any kind of application like news feeds etc. >> onto it's users. Instead it just gives the user a choice of >> programming languages to roll their own. All BALL does is kinda >> web without servers. Applications run in the web caches instead.))) > > Amazing madness. Just tried to download from > http://ball.askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=download > but I get 404. Ups. How came this directory to be empty? I fixed the links. > So it is written in scheme? I will be barely capable of figuring > out what it might be doing. I don't see this as a problem. I myself came pretty late in my professional life to learn Scheme. There are a few facts why it's a good language to do a) specifications b) prototypes. (I don't want to advocate here too much, almost any language will do. Nevertheless): * Small: the whole standard (r7rs) comes at 87 pages. That is including ~20pages formal semantics etc., which a "normal programmer" will skip. You'll learn it in few days. http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html * Almost no syntax. (S-expression are themself free of semantics [and a subset is equivalent to XML].) What you write in Scheme is basically some abstract syntax tree of the program you have in mind. ASCII-art how to express a concept, as in "normal" languages is missing. So whenever one resorts to some "config file syntax", XML driven helper prog etc. with other tool chains, you one just keeps writing /embedding the domain specific language in the over-all primitive syntax. * Powerful, general control features. (call/cc) One normally never ever needs it. But it allows to escape, once you messed up your prototype and do things quite a different way. * Typically it's only a very thing layer atop of C libraries (making call safer for the sake of simple development). * So many implementations (because the difference between implementations is about a big as the difference between say Perl, Python and PHP). And it's easy to be implemented in any language and implement any language in Scheme (possibly inefficient, but easy). But the main point is: when you restrict yourself to write in portable Scheme - which really, really is a restriction and pain in the ass for the programmer - the resulting code is very easy ported into any language better suited for the final implementation. So: simplicity and openess had me choose it in the beginning. (After all at that time I had no idea what we would actually need.) In fact at this time I'm looking into how to replace as many parts as possible with external libs. (Those Scheme we choose so far make it rather easy to link to C libs.) > I was led to this page saying it would contain a p2p messaging > software.. but I see some linked data navigation: > http://ball.askemos.org/Abb8999dd38524dcc113f977d378a9ee0?_v=footnote&_id=1159 > > Maybe it's the wrong time of day to do this. Well: the app, which drive the web site is far from perfect (see hoist.askemos.org ) It was budget development for a small local library. But they wanted "semantic". So it's a simple RDF-style thing. The downside: you might end up at pages representing nodes which have close to no content and are just there to glue some concepts together. At the other hand I personally learned to love the app in a way to keep tabs in my private notes on all things I come across. Much better that any personal wiki I used before. Especially due to the triple structure of search results you see from a search result much more than with more traditional interfaces, where you typically need to follow the link to learn that you did not want to know about that particular hit. (E.g. try "repudia*" in the search box at asekmos.org) >> That code layer I want to replace, does byzantine failure tolerance >> and collaborative state transfer. This could be done atop of any >> chat-alike protocol. It takes one channel (chat room) per state >> machine to coordinate updates and distribute the current state in >> case a node responsible to keep a state machine was offline during >> some update. > > Ok, I managed to understand this paragraph. So you need the pubsub > API tg is working on. psyced has that too, but it's not very P2P... > only if i get it to run behind Tor. Yeah, got that these days when exchanging several mails with Christian Grothoff. PSYC seems slightly a miss-match. Though still rather close in a way. >> Coordinating updates would be easy even using channels, which allow >> only restricted character sets and small messages. It there are only >> some hash codes and fixnums to be exchanged. However: there MUST >> be some authentication (e.g., cryptographic signatures) for messages. >> (Otherwise it would die fromthe first Sybill attack.) > > PSYC happily deals with binary content. > >> State transfer however is different. Currently it's a custom protocol >> over HTTPs similar to bitorrent. When, say a SQLite database is updated, >> it's written blockwise, those blocks are transferred one-by-one. (We >> never update the blocks; theirs hash forms a Merkele tree and blocks are >> replaced upon update.) I don't see this being efficient in non-binary >> encoding. > > since you'Re doing your own state thing, you can keep it binary. > >> (((Side note: we have a few real users, who have no idea that there >> is some distributed, fault tolerant database underneath their software. >> They just expect "reasonable" performance when they post updates >> under the expectation that "this is a web site". When replacing >> parts, I should not break their experience.))) > > amazing.. we should probably get some hints from you... > it's not my home turf at least. Well, Askemos is basically only a concept with BALL a proof-of-concept implementation. (In the beginning most people did not believe it would be possible to build such a system at all. I myself was not convinced. The rights management system is horribly strict and don't get me started what it means to implement an interpreter for user supplied scripts, which then has to run on several distinct runtimes using different libraries, different hardware architectures (arm/intel 32/64 bit etc.) and still verify each and every operation by exchanging SHA265 hash codes over the results: we had the point that everything seemed to work except floating point arithmetic. Turned out that different libs would provide different precision when printing. Too bad for the hash.) But I'd love to be helpful to get the ideas behind implemented in all sorts of other software. After all: we're sort of convinced that those are ethical principles, which could really help to free people from the need to trust any "service provider" by just sampling their personal group of half-way-trusted providers without the need to trust any of them completely. (Including their own hardware and even person.) This should not be confined to some single implementation. >> On Oct 4 2013, K???ra wrote: >>> On Tue, Sep 24, 2013 at 2:14 AM, carlo von lynX wrote: >>>> so, congratulations to the Tent team for implementing something >> >> Please someone enlighten me about the "Tent" you are talking about >> here!! I vaguely recall some "tent" team from about 20-30 yrs ago. >> You don't mean that one, do you? >> >> Otherwise "tent" looks like a bad search term. :-/ > > I think we were talking about https://tent.io/ Thanks. Nice. Looks like something to be implemented in BALL. Again: replace the idea of a server with a group of servers synchronized in byzantine agreement. Makes you independent of the server in case some bad guy decides to take it away by physical force or administrative power. > > >> For those reasons I "expand" from "my own computer" to "a known >> set of computers". > > Ack. > > Sorry for the delay. > > > -- [email protected] > https://lists.tgbit.net/mailman/listinfo.cgi/secu-share -- [email protected] https://lists.secushare.org/mailman/listinfo.cgi/secu-share
