Luddites Prototype

Links to this page
Edit this page
Entry portal
Advice For New Users

Discussion about the current Luddites Prototype being used to explore the design concepts & implications.

At present have:

In near term need to:

Lawrie's Python Code Rewrite (v0.3 Apr 2018)

Lawrie is currently rewriting Colin's original prototype, and his script front-ends, into a single integrated python package and client scripts. All code is being developed in python3, though is also being tested with python2 so works with both versions - which does need some contortions in places. Specifically, the biggest differences is with handling of str, just byte arrays in python2, but are Unicode strings in python3 with bytes as a distinct data type, and en/decoding("utf-8') needed between them (main impact in & en/decrypt code). Some std module imports have changed - currently urllib used in the most obvious. And import handling has changed, necessitating some sys.path hacking to handle running code both within an uninstalled package, and directly within the dir (see for this).

The key externally accessed modules I've created in the new luddies package are:

Internally, other key modules are:

This rewrite is being done under git control with a remote repository at

Access to this is via manually configured SSH keys. Lawrie & Colin (soon) have R/W access, and the @ludditestester key (in admin folder in repository) has R only access (so we can give it out to people who want to play with the prototype).

Key data structures

Contacts (in

Each contact is a dict of the form:

 {handle, alias, description, password, published, certificate, my_handle} 

The new module implements a Contacts class to manage this data, loading/storing it to the user's contacts file (default /ddm/contacts.dat).

Identities (in

Identity is a dict with the following details on each of the user's identities:

 {handle, alias, description, password, published, certificate, privkey, lastpoll, nextpollint} 
where: Certificate is a dict with the following alg & key details for a contact:
 {handle, dropseed, timeslice, alg, pubkey, valid_from, valid_to} 
where: The new module implements a Identities class to manage this data, loading/storing it to the user's identities file (default /ddm/identities.dat).

Messages (in

Messages are a list of items with the following details for each message saved:

 [my_handle, remote_handle, polled, time, msg_text] 
where: The new module implements a Messages class to manage the users saved messages list, loading/storing it to the user's messages file (default /ddm/messages.dat).

KVS Data format

Currently on the solipsys web KVS currently in use, data is sent as b64encoded strings/bytes, cleartext except for encrypted messages.

Lawrie has changed the format to JSON (JavaScript Object Notation), which is a language-independent data interchange format. Parsing libraries exist for many languages, including python, so I believe this makes it a pretty portable, text based format. Using this encoding could avoid the need to b64encode the data, since it is already in text form, save that the current script requires it. For more info on JSON see:

The two main structures we need to support are:

Links to this page / Page history / Last change to this page
Recent changes / Edit this page (with sufficient authority)
All pages / Search / Change password / Logout