let's get together - how we orbital

[du5t]

I think we need group formations that are created by agreement among more than one person. Otherwise we got a singleton Founder. Thus my interest in group-forming protocols. And by protocol here I mean human-level, more like Roberts Rules of Order or the rules for a card game than TCP.

yea, i agree! i was trying to communicate (poorly) that the observance of protocols is a traveller at-will thing, since cypherspace can sometimes be treated as effectively infinite, and travellers can operate almost totally unknown varieties of spaceships. what that means is that the things that spaceships do (non-person machines) is separate from what their travellers do. so the mechanical creation of an orbital is a qualitatively different thing than the travellers' observing of the orbital as a thing. the spaceship part is the crypto boundary and message processing; the traveller's part is the social connection.

i think that this separation is probably a permanent one. this is because any spaceship could just start up another orbital with slightly different traveller policies or slightly different membership lists. basically you can always vote with your "feet". this principle of agency is i think a very important one that makes it a freer "space".

i think all of this is to say that i think we agree about this, tho ;)

so i thought about it some more--i think there needs to be an addition to the schema, namely agreement, like you described in the linked github issue. something that accomplishes the task of "terms and conditions" but in a much more cooperative sense, since nobody can be an orbital the way a corporation can be one with the service it finds ways to compel people to use.

the trick is to handle agreements without them becoming what programmers call "application state", since that becomes some object that can be fought over (and can't really be stored in cypherspace, afaict?). i think it's not so difficult tho; spaceships can sign agreement objects and their revisions etc., and entrants can examine agreements when they hail an orbital. if the signatures and member keys line up, the agreement is probably valid.

likewise, if a ship breaks some agreement, the other signatory ships can notify their travellers as well as respond automatically if there's something to that effect. a cool example would be, "resident does something well-defined to be really bad (threats, leaks, etc.)-->other residents automatically establish a new orbital with everything matching the previous one except for the offending resident removed."

establishment of an orbital thru quorum like you mentioned could be very similar.

private membership lists and agreements don't seem impossible either!

[du5t]

i'm thinking a good way to move on this is build up a really sparse minimal model that involves an agreement between spaceships (+ travellers) that yields an orbital that works in a certain way.

i still think the most minimal example is no-agreement recipient lists, but it's also true that doesn't go anywhere, so we need something a little bit more flexible.

[dominictarr]

it's a bit hard to follow this because your are being very abstract. can you give a concrete example of some possible orbital

[bhaugen]

the trick is to handle agreements without them becoming what programmers call "application state", since that becomes some object that can be fought over (and can't really be stored in cypherspace, afaict?).

Don't understand agreements as application state. Example?

(And I agree with @dominictarr - examples are the way to move forward at this stage.)

[bhaugen]

This comment might be off-topic. More on that below.

I think that Simon Peyton-Jones composable contract stuff is important for computable agreements (like group terms and conditions), so we can decompose them into components that can be combined and recombined. But I can't understand his stuff. Don't have the required background.

I have had conversations with people who do, and I don't understand them, either. For example.

Here's an attempt at an object-oriented version but I don't understand that yet either.

I posted links to this stuff in Patchwork. which three people responded to, but neither of you two. Did it seem useless, or uninteresting, or you didn't have the required background either?

I'm trying to decide whether to pursue this seriously or not. As in, dive in and try to understand and work with the concepts, or run away fast.

You were the two people I actually wanted to think about this with. If you also want to run away fast, or @du5t if you think this is off-topic for orbital agreements, please let me know and I'll delete this comment.

[bhaugen]

See also Greg Cassel's Agreement Based Organizations.

If you like Greg's ideas, we could probably bring him into this thread for some examples of group-forming agreements.

[du5t]

i think this is all good! (@bhaugen i'll read that stuff ASAP, i promise.) one thing i explicitly want to avoid is strongly opinionated frameworking. (of course spaceship itself is a framework, but i'm trying to keep it sparse ;) mechanisms of agreement very quickly balloon into whole political systems, which i want to avoid. conceptual atoms would make me much happier, as long as they were effective.

in the service of that, let's start with a minimal example: 1v1 agreements!

some alice and bob:

1. alice wants to start an orbital for sharing cool stuff. alice is great friends with bob, and bob is into the things alice is into. they're social, so they want to invite more people into it, but they don't want it to be some public thing that gets out of hand.

2. alice starts an orbital by posting a record containing a resident list (just alice and bob's pubkeys to start), as well as a "deciders" list (same contents). maybe they also indicate the way they run things (unanimous agreement):

   {
    "type": "orbital",
    "deciders": ["ALICE_KEY", "BOB_KEY"],
    "residents": ["ALICE_KEY", "BOB_KEY"],
    "agreement_type": "unanimous"
   }

3. bob and alice can send messages to each other thru this orbital, but it's not really a step past a private message yet. luckily, alice has a friend, crista, who is totes into the same things. so alice posts a revision of the orbital record to the deciders list of the orbital:

   {
    "type": "orbital",
    "deciders": ["ALICE_KEY", "BOB_KEY"],
    "residents": ["ALICE_KEY", "BOB_KEY", "CRISTA_KEY"],
    "agreement_type": "unanimous"
   }

4. bob looks at the diff, checks out crista's posts or w/e, and decides he's into it. he signs the revision, approving it. so now both alice and bob, the deciders, have signed the new orbital revision. (assuming alice's sending it works like how i think ssb works, where posting and signing are the same.) now that latest decided revision is the one in effect.
5. now every time alice, bob, or crista send a message to the orbital, they all receive it. if someone wants to make a change, it's up to alice and bob to both sign a revision. changes don't have to be "residents_list" either, they could be basically any kind of record, like "topic".

---

comments

• ok so i completely avoided creating an agreement object in the example. but the "agreement_type" property could easily be another record id which associates with an actual agreement that spec-satisfying spaceships will follow. unanimous agreement among deciders is just simple enough to avoid creating an agreement object on its own.
• a separate agreement object would allow meta-revisions, namely changing the actual "how" an agreement represents (such as "majority rule" --> "dictatorship").
• @bhaugen: the continuous yak shaving revising of the orbital as a record is the "state" part of this--suddenly there's a "constitution" that is independent from each of the individual people involved.
• note that this has very little to do with orbitals themselves: orbitals can be subject to agreements which constitute "policy", but there's no inherent reason why they have to be.

[bhaugen]

i'll read that stuff ASAP, i promise.

@du5t do you have a basis to understand it? I don't. I think it is important and will be useful, but so far, I have not had time to do the necessary study, and haven't found anybody who can explain it so that I can understand it. But I think that computable agreements will be composites, combinations of components, and not just text. Thus, what are the components? And how are they combined?

[du5t]

so, is https://github.com/du5t/spaceship/issues/1#issuecomment-216733114 good enough to roll on?

[bhaugen]

Ok with me. I'll learn more then I can try something.

[du5t]

@dominictarr whatchu think