Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 11:51:10
Askemos docs are working for me again - it may have been my wifi at fault, so I wouldn't worry about it. Reading your response and reading Askemos' docs, I'm inclined to say our projects solve fairly different problems. Let me step through the Mint.com example to hopefully clarify /...\ have to be a Citibank dev to dev Citibank. I'd need to research it more deeply, but I suspect that Askemos' protocols could be implemented in this extensions-architecture as a set of reltypes. It might be used to cluster multiple Worker scripts and remote services which all implement /...\ related.  Though I feel I'm missing something basic.  Like a super-simplified paragraph of the over-all idea. > Askemos appears to solve trust in distributed application-state, correct? I'll need to read more deeply. I'm not a native English speaker. Notably here
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 14:51:13
these. It still looks related. Though I feel I'm missing something basic. Like a super-simplified paragraph of the over-all idea. > Askemos appears to solve trust in distributed application-state, correct? I'll need to read more deeply. I'm not a native English speaker. Notably here /...\ assume/agree to be correct. Method: stolen from (modeled after) the legal system: don't aim for absolute truth. Rely on judgment and witness. So Askemos is somewhat like the web with the servers removed. (And not restricted to Web, though that's the easiest model to explain it). Instead /...\ malfunction is spotted and handled (ignored). (At least while there are less than 1/3 bad nodes.) Hence I'm inclined to say "Askemos solves trust BY distributing application state". Especially by distributing it to parties having a stake in either a) correct results b) conflicting interests iff they
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 10:45:08
done under control of the user at the client side, correct? Yes, that's correct. For the sake of brevity, I'll respond to Askemos' A) and B) alternatives by saying, they make sense, and so long as the integrity of each component is maintained (which I expect is what /...\ Askemos uses VMs to ensure) then it's a similar approach. The client uses a trust hierarchy, in which the Page is most-privileged, and all Workers are given least-possible privilege. Deciding which participant is the Page is mainly a question of who should be trusted with the information /...\ looking for reltypes that it understands, and then begins communicating with the endpoints of those links according to their reltype specs. By publishing Askemos' protocols as reltypes, you standardize the protocols. For a simple example, if Askemos used a "heartbeat" protocol in which ping messages need to be exchanged regularly
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-09 09:25:35
architecture: "In-Application Sandboxing with Web Workers" http://pfraze.github.io/2014/03/08/in-application-sandboxing-with-web-workers.html "Communicating with Web Workers using HTTP" http://pfraze.github.io/2014/03/08/communicating-with-web-workers-using-http.html Askemos appears to solve trust in distributed application-state, correct? I'll need to read more deeply. The trust question I'm investigating is application-integrity during /...\ part of the network, and so origin is more granular. Servers may apply clustering algorithms to share state authority, and so (I suspect) Askemos' protocols should be applicable to them. Servers remain a network primitive for more complex topologies. Another notable aspect of trust is data-containment, which Workers solve /...\ This excites me for applications like Mint.com, which really needs proper isolation to function ethically. I'm having trouble loading some of Askemos' docs, but I look forward to digging in a bit. Ping me in #stackvm on freenode (pfraze) sometime. Be well, Paul
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 11:15:55
schrieb Paul Frazee: Reading your response and reading Askemos' docs, I'm inclined to say our projects solve fairly different problems. Let me step through the Mint.com example to hopefully clarify the differences. Reading your message I'd agree.  Looks like our projects solve kinda complementary problems, which makes /...\ nice example to show where our approaches take a different route to the same result.  (While using the same "miniature OS" analogy.) With Askemos the roles would be reversed.  As I understand your words, citibank would have to prepare their website with some kind of "extension area" where /...\ mint.com is going to be embedded.  Though the embedding itself is done under control of the user at the client side, correct? With Askemos we'd have two alternatives: A) citibank too could be an application run in byzantine fault tolerance.  (This had pros and cons: four
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-09 11:30:40
machine replication > Also, regards your notary system: how are notaries assigned to > officiate a particular "place" > (is that correct Askemos terminology?) Apropos terminology: we did this in German explaining rather common terms to detail ad nauseam. The phrase we settled on was "a notary /...\ feed is an append-only singly linked list of messages, owned by an > id. Which is pretty much the same structure as in Askemos: a OID is a canonical hash of some meta data of a frame (in the sense of key-value pairs). The frame hold the current /...\ reassigned. The idea is to optimize for > simplicity even over convenience. That's a laudable goal. With Askemos we are looking especially toward "long term availability". After all contracts often cover many years. That's the rationale behind treating all crypto as a plug in of some
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-09 10:40:18
pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html After reading I can see that this is pretty much in line with the model proposed under the name Askemos. From a practical point of view it also looks much like the way we program our agents. However I'm left with one question: how does this relates
Paul Frazee [LibreList] Re: [redecentralize] Avatar "operating system for the internet" 2014-02-03 11:04:28
takes.  Underestimating is pretty simple. Otherwise I had similar experiences.  Avatar's goals look pretty similar to our ideas for Askemos (though ethereum is even closer).  Except that we immediately scaled back to leave browser integration for later. A decade of experience later
Jörg F. Wittenberger [LibreList] Re: Trustworthy Contract Handling - Comparison Of Approaches 2014-08-03 14:56:05
three oracles to behave maliciously, be offline, or even be hacked without affecting the execution of the contract. This is the same concept as Askemos deploys. However: when written like this, one might assume the 7 was a number one could choose arbitrarily. That's an unfortunate wording. One could
Jörg F. Wittenberger [LibreList] Re: [redecentralize] FireChat in Economist 2014-06-03 08:29:42
practice (to the extend that the website itself is hosted that way).  Though at least Ethereum works towards the same goal. (With Askemos taking the per-contract byzantine agreement route and Ethereum using the global blockchain approach.) Best /Jörg But all the intentions, architecture, security, community engagement
Eric Mill [LibreList] Re: [redecentralize] FireChat in Economist 2014-06-03 10:35:02
practice (to the extend that the website itself is hosted that way).  Though at least Ethereum works towards the same goal. (With Askemos taking the per-contract byzantine agreement route and Ethereum using the global blockchain approach.) Best /Jörg But all the intentions, architecture, security
Paul Frazee [LibreList] Re: [redecentralize] FireChat in Economist 2014-06-03 10:17:33
practice (to the extend that the website itself is hosted that way).  Though at least Ethereum works towards the same goal. (With Askemos taking the per-contract byzantine agreement route and Ethereum using the global blockchain approach.) Best /Jörg But all the intentions, architecture, security
Jörg F. Wittenberger [LibreList] Re: [redecentralize] FireChat in Economist 2014-06-04 10:32:38
practice (to the extend that the website itself is hosted that way).  Though at least Ethereum works towards the same goal. (With Askemos taking the per-contract byzantine agreement route and Ethereum using the global blockchain approach.) Best /Jörg But all the intentions, architecture, security, community engagement
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-03 11:31:11
precisely where you expect it to be and is not leaked elsewhere.  Downsides: Bitcoin is open-join.  Anybody can participate.  With Askemos you get close-join.  Like WhatsApp: the owner needs to accept the other party before messages are taken. Actually I'm currently gathering more
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Re: Trustworthy Contract Handling - Comparison Of Approaches 2014-08-15 19:21:54
underlying info anyway. Why not expose it as an independent proof? > Quite... the drogulus is supposed to be application agnostic. (as is Askemos ;-) >> So I need an environment where I see agents (be them accounts >> representing human users or automated, autonomous processes) >> communicating
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-20 13:10:03
societies that > work best and see how they do it. BTW: That's been the concept we followed when we came up with Askemos. Understanding that we currently have an internet akind to some kind of feudal society, we asked: what came next and how did they
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 08:34:56
simpler things that do not require consistency. I see. I filed a note to self for SSB under eventually consistent DB layer. You see: Askemos does NOT depend on BALL as an implementation. I'm always eager to replace as much of our code with things from elsewhere until
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 08:53:52
think the web-of-trust is inevitably what we'll need, I think so too.  Actually I think a simple registry in an Askemos compatible system would do.  Users would choose one or more registries and publish their peer's public key and status.  Plus some
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 03:28:23
description of the algorithm? Also, regards your notary system: how are notaries assigned to officiate a particular "place" (is that correct Askemos terminology?) The data model in secure-scuttlebutt is very simple. There are messages, feeds, and ids. a feed is an append-only singly linked list
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Avatar "operating system for the internet" 2014-02-03 09:53:54
resources it takes.  Underestimating is pretty simple. Otherwise I had similar experiences.  Avatar's goals look pretty similar to our ideas for Askemos (though ethereum is even closer).  Except that we immediately scaled back to leave browser integration for later. A decade of experience later and having