OpenAppJS Technical Update

This is exciting progress! I will be grateful for your suffering when it's my turn to learn mercury. Loved the routing#8 conversation!

I can see gossip as a great protocol for value streams.

• Published by a value network.
• Like Activity Streams, but about value network activities.
• Needs, ideas, offers, requests, plans, new recipes, creations, work to do, stuff we need, notices about income and income distribution, etc.

I can't see it much for contract-formation between agents, which is a back-and-forth protocol that needs stronger consistency, and is nobody else's business until the principals agree on something. But maybe I am missing something?

Many thanks for another great update @simontegg - keep 'em coming :)

I do wish @tav and @tomsalfield would take the time to engage here too because I know they've done useful relevant thinking and work related to all this stuff.

One thing @tomsalfield mentioned to me the other day when I mentioned the plans for 'people' and 'groups' apps was that 'groups' possibly isn't the way forward and that perhaps 'people' and 'spaces' would be more useful. We didn't actually chat any more about it though so I'm not really sure what he meant/ what the difference is. Hopefully he'll chime in. If not I'll try to remember to ask him and then feed back :)

@josefdaviescoates - @tav said something about Ethereum in another Loomio discussion that I can't find now that is what got me thinking about the minuses of blockchains...always hoped for a re-appearance to learn more.

And yeah, would like to understand what @tomsalfield meant by spaces.

Hey @bobhaugen it was actually me relaying something @tav had written to me in an e-mail.

Here it is:
https://www.loomio.org/d/ELxZy1TJ/what-do-you-all-think-about-eris#comment-130428

i'm currently 88c9aa687a076aa530cc18d7921cec1f90f7779ad25915204d272a695072f58a on phoenix, we hang out in #stackvm (node.js mad science), #scuttlebutt (phoenix and secure-scuttlebutt), and #virtualdom (mercury) on freenode irc.

another good description of the "secure gossip protocol" is in the secure-scuttlebutt README:

SecureScuttlebutt uses a signed block-chain per identity. Each block points to the previous block, the signing key, and contains a short message and a signature. Every identity has their own block-chain.

Each block-chain is an append-only data structure that can be written to exclusively by the keys' owner. Since the chains are append only, replication is simple, request the chain for that id, since the latest item you know about.

Now, each node is the master of their own feed, so scuttlebutt replication is just like doing many simultaneous master-slave replications.

Since messages are signed, and replication is eventually consistent, it does not matter if A receives B's messages via C, they can verify B's messages offline (i.e, when A is out of contact with B)

@bobhaugen: you could send encrypted messages back and forth through the network until you reach an agreement, then publish the agreement to a wider audience. gossip is how the network distributes messages, it doesn't mean everyone needs to see your messages.

@ahdinosaur - I understand that gossip messages can be private. I was thinking more about an elaborate protocol with eventual consistency for a simpler situation that would like consistency right now: binary agreement. So I am ready to believe that I am missing something, since lots of people seem to think that blockchains are the way to go.

This is the human-level protocol I want: http://conversationsforaction.com/cfa-playground

And I think I would like all of the messages in that conversation to be added to the same append-only document, signed every time. Unbroken record of the whole economic interaction.

If that can fit within gossip and not confuse the participants, it's all ok with me.

@bobhaugen cool, yeah as far as i know, the Conversations for Action protocol would work great within the per-agent message feeds being described. i'm quite excited to make this happen, it will probably involve various message types relating to the various stages of the conversation. would it be possible for you to document the CfA protocol through descriptions of message-passing (e.g. "at this stage of the conversation, here are the possible messages to send and the respective next stages")?

@ahdinosaur I'll give it a shot next week some time.

I started a CfA discussion here. More to come after breakfast.

@ahdinosaur - just coming back to this conversation after 7 months (last message above). We got somebody interested in some NRP UI experiments, who has some JS experience but is also eager to learn.

The state of the JS client-side frameworks apparently continues to warp. If I understand correctly, you fell in love with mercury, and then fell out of love and went back to React. Is that correct? Can you say more about why?

(I was just reading this, which made sense to me, but then I don't actually do this kind of work yet:
http://futurice.com/blog/reactive-mvc-and-the-virtual-dom
It's in the mercury camp.)

@bobhaugen sweet. you're correct in that there are no clear winners in client-side frameworks, we're only using React because it's easy to use, well-supported, and has an active ecosystem of re-usable components, mercury is still awesome but requires more work to use, neither is perfect. however i reckon there are clear winners in the patterns that are being adopted, of most interest to me are "functional reactive programming" and "kappa architecture". only time will tell what actually happens, but maybe this helps share where i'm at.

I'm in awe of Omniscient right now.. I think it looks really great without being too different (ie: written in ClojureScript)

@robertguthrie -if I understand this correctly, Omniscient rides on React?

So, does that give you access to those re-usable components that @ahdinosaur talked about? Plus immutable data? Or is it off in its own universe?

And Mikey, what are a couple of those re-usable components that you get the most benefit from?

I'm interested in where this stuff is going. Seems like each of the hot js frameworks evolves in a succession, where they fix what they thought their predecessor did wrong. The problem is the succession may have no end...so you pick something, and now here comes something better (maybe)...

@ahdinosaur your urls don't work. These do:
https://github.com/ericelliott/irecord/blob/84450a50aa9dd3a53c4999cb9d55daf9fecbfecd/reactive-programming.md
https://gist.github.com/ahdinosaur/bd1a0005154656217aae

regarding Omniscient, yes it lets you use re-usable React components, plus it uses Facebook's immutable data structures (including the respective cursors library), so is in the same universe.

what's nice about active ecosystems is having access to everything you can imagine, to use or learn from, similar to the Node.js module ecosystem in general. i can't single out individual components that provide me with sheer awesome value, it's the ecosystem in general that does.

i agree that hot frameworks will continue to succeed and die, that's why i'm much more interested in learning the underlying patterns that won't become obsolete in a few months. also, i prefer using libraries that implement a focused scope, as they have a longer lifespan, and are much easier to swap in and out as conditions change.

sorry about the urls, markdown seems to work differently in Loomio's new angular interface.

"markdown seems to work differently in Loomio's new angular interface."

Sure does. Now my plain urls that worked in the previous interface don't work in this one, and yours that did not work in the previous IF do work in this one.