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

Parent
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-09 11:30:40 (6 years 3 mons 29 days 11:46:00 ago)
Am 06.09.2014 12:28, schrieb Dominic Tarr:
> Jorg,
>
> Ah I had not heard of BALL, I have been reading through the documents
> at the "whilepaper" link.
> I think I can vaguely see where you are doing with this, but I would
> like to understand how your replication
> algorithm works. Do have have a link to a description of the algorithm?

A high-level description
http://askemos.org/index.html?_v=wiki&_id=617
more technical here
http://ball.askemos.org/?_v=wiki&_id=1339
(follow "consensus and synchronization protocol" for state 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 is commissioned to audit a 
process".  (whereby "process" is any active agent).

But I want this to be good English.  So if "officiate" is better, we 
should switch.

To the point: notaries are a property of a place.  In the demo this part 
is not very pretty yet:
http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a?do=notaries&version=19&login=public
An agent (here the wallet application) can control the list of notaries.

There is nothing to prevent the agent from doing stupid things like 
removing all notaries.

> The data model in secure-scuttlebutt is very simple. There are
> messages, feeds, and ids.
> a 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 state (and hidden from the 
application layer some past state) of the application at the place.  It 
is the unit of replication.  I.e., a SSB feed corresponds to a place.

Message&message is another interesting topic.  We have two:
http://askemos.org/index.html?_v=search&_id=1302

>   The id is just the hash
> of the public key used to sign the messages in a feed. A feed may not
> be signed by mutliple keys
> and the key may not be 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 sort. It simply changes too fast.


> This make both replication and verification conceptually simple. It is
> not necessary to trust any
> devices you do not have in your physical control.

Same here.  Up to not trusting any single device outside your trust set 
with the update process.

>
> I think this will be enough to implement "web 2.0" style "social"
> applications such as twitter.
> Maybe not as convenient as twitter, but decentralized, and ultimately
> more flexible.
> More flexible, because not having centralized control over the service
> means I will not be tempted
> to prevent other people building on top of it, as twitter and it's
> like are increasingly doing.
>
> Do you have documentation on how your notary system and data replication works?

Hope so.  See above.  Also for the fun of it, try the search box in the 
upper left of ball.askemos.org and askemos.org (technical vs. 
"philosophy").  It is a sqlite full text search coming back with 
subject-predicate-object triples.  Often quite useful.

Questions are very welcome.  I'm working on the documentation side now. 
(Enough feature creep already. ;-)

Best

/Jörg

>
> Dominic
>
> On Sat, Sep 6, 2014 at 12:56 AM, Jörg F. Wittenberger
> <Joerg.Wittenberger@softeyes.net> wrote:
>> Boah, what a mistake I made!
>>
>> It's NOT 80kLOC it's 80Kbyte.
>> 60% for the HTML user interface, 932 lines "real code", including all
>> the SQL and non-essential functionality.
>> Only about 230 lines (pur functional code and again a lot HTML) one
>> would ever want to manually verify to be sure it does not violate the
>> required invariants.
>>
>> After all: it's supposed to be easy to audit, not prohibitive expensive
>> and error prone!
>>
>> Sorry for the noise, I had to correct that.
>> /Jörg
>>
>> Am 06.09.2014 08:34, schrieb Jörg F. Wittenberger:
>>> The payment system (current draft) for instance is here
>>> http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
>>> that is, this is one wallet of it. You want to log in using "public" to
>>> find the actual thing.  It's controlled by a single (though having
>>> 80kLOC large) source file:
>>> http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
>>> (be sure to read that in whitespace preserving source mode, do NOT let
>>> the browser mangle it and skip XML comments).

: