Object Model
The core object model of Oulipo is heavily based on Udanax Green and its tumbler concept.
<network> . <node> .0. <user> .0. <document> .0. <element>
An example (in this case a link element) would look like
1.2.0.3.5.0.1.1.2.0.2.10
| Field | Tumbler Address | Description |
|---|---|---|
| Network | 1 | MainNet |
| Node | 1.2 | Node 2 (used to address the specific server) |
| User | 1.2.0.3.5 | User 3.5 |
| Document | 1.2.0.3.5.1.1.2 | Version 2 of document 1.1 |
| Link | 1.2.0.35.1.1.2.0.2.10 | 10th Link of document 1.1.1 |
Take a look at the class diagram of the Oulipo model. At the top is a Thing. The thing maintains a reference to its resourceId, which is a ted scheme followed by the tumbler address of the link.
resourceId=ted://1.2.0.3.5.0.1.1.2.0.2.10
The Node class maps directly to the < node > tumbler field.
ted://1.2
The node contains the publicKey of the person creating the node. Only a user with the corresponding private key can modify the node information.
You can see that Node has a field called accounts. This is a collection of all user tumbler address attached to this node. If the allowUserToCreateAccount is flagged as true, then any user can create an account on this node. Otherwise, it is up to the administrator of this node to create users.
Node also has contact information similar to that maintained by ICANN for domain names. In the future Oulipo will also have a DNS type system that will map these Nodes to an IP Address.
A person or user is a type of Thing. A user is a component of an aggregate Node. The Person class maps directly to the < user > tumbler field.
ted://1.2.0.3.5
A user has a publicKey for unique ID but can also add a Xandle or userName. A Xandle can only be assigned to one user per network but can be changed at anytime by the user. At that point the Xandle becomes free for others to register and use.
Xandle is a term originally coined by Ted Nelson and referenced in Literary Machines 87.1. It cost 100 each to reserve at the time.
You can see that User has a field called documents. This is a collection of all document tumbler addresses the user has created.
A user can also have payin and payout addresses for micropayments (currently they are bitcoin addresses but that may change by production release). The idea is that a user can send cryptocurrency into their account so they may view paid content. They can also send cryptocurrency out of their account when others read the users content.
A document is a type of Thing. A document is a component of an aggregate User. The Document class maps directly to the < document > tumbler field.
ted://1.2.0.3.5.0.1.1.2
The document tumbler field must contain exactly three digits. The first two digits (1.1) are arbitrary but by convention earlier documents will have earlier numbers. The last digit (2) is the version of the document.
You can flag the document as world readable by setting isPublic to true. This helps satisfy Xanadu Principle 11:
Every document can have secure access controls
You can add a title and description to the document for allowing other users to discover your document. In Literary Machines 87.1 (4/52), it mentions that the meta information would be contained in meta-link. In our case, we deviate from this and allow document meta-data to be directly referenced from the document tumbler address.
There is also a links field in the Document class. This is a collection of tumbler addresses referencing the links of the document.
In the Udanax Green system, an element field will be either a byte or a link. With the ted scheme defined in Oulipo, we will also allow VSpans to occupy the element field
A byte element references an individual byte within the document space. The first digit of a byte field is always 1. Below, we see a reference to byte 345 within document 1.1.2. In the VSpans section we will show how we define a range of bytes.
ted://1.2.0.3.5.0.1.1.2.0.1.345
A link element references a link within the document space. The first digit is always 2. The second digit is the sequence. For example, the next link created would be 2.11.
ted://1.2.0.3.5.0.1.1.2.0.2.10
The contents of a link are one of the more interesting parts of a xanalogical system. Udanax Green refers to the content within a link as an endset. It consists of 3 parts
| Type | Description |
|---|---|
| From | VSpan ranges coming 'from' a document |
| To | VSpan ranges going 'to' a document |
| Three | Link type: jump, paragraph, comment |
So for instance, say we have link A
| Type | Example |
|---|---|
| From | ted://1.2.0.3.5.0.1.1.2.0.1.1~1.500 (Doc A) |
| To | ted://1.2.0.3.5.0.1.1.2.0.1.100~1.10 (DocB) |
| Three | ted://1.1.0.1.0.1.0.2.10 |
Lets say that ted://1.1.0.1.0.1.0.2.10 represents a jump link type. Then link A connects positions 1-150 of document with positions 100-110 of Document B. So we user clicked anywhere in position 1-150, their view would jump to position 100 of DocB.
This is covered in more detail in Literary Machines and also at
http://www.xanadu.com.au/ted/XUsurvey/xuDation.html
VSpans (virtual spans) are a bit of a special case. They aren't tumbler addresses in the original Udanax Green implementation. Udanax has a strong concept of defining resources through a tumbler addresses but VSpans themselves are not treated a resource. They are part of RPC parameters. For example, a Udanax request (or command) for retrieving content would look something like this:
5~1~v~0.1.1.0.1.0.1~1~0.1.1~1.1500~
The 5 in the beginning means the command is for retrieving content. 1.1.0.1.0.1 is the tumbler and 0.1.1~1.1500 is the VSpan range.
For Oulipo, we would address this range directly with 1.2.0.3.5.0.1.1.2.0.1.1 being the tumbler address and ~1.1500 indicating a width of 1500 characters starting from the first character.
ted://1.2.0.3.5.0.1.1.2.0.1.1~1.1500
This is a useful representation because it means we can specify a byte range through addresses, which allows us to treat a VSpan as a resource rather than it being a parameter in a command (RPC approach).