Hey! Thanks for that feedback! i really mean it, too. We're doing our best to accommodate a wide audience. If the technical language doesn't connect with you, i'm happy to personally walk you through what it means. Come join us on a hangout (they happen Wednesdays at 21:00 GMT). In preparation, i can give you a brief summary.
The technical presentation of the network model breaks down into two portions. First, there's a detailed presentation of the model using what might be called a naive approach, modeling the network as a graph where the nodes are Synereo code + users, and edges are communication channels between the nodes. The naive model associates a certain model behaviors at the nodes. We acknowledge that this model is naive -- at least because the graph is changing as result of the behaviors of the nodes. People introduce other people to each other (creating edges), new people join (creating nodes), some people leave (deleting nodes). We present it that way, however, because the mathematical formalism that's more appropriate to modeling this kind of situation is less familiar to a lot of developers and other people who might want to understand how to build this.
In the second portion we give a brief intro to the mathematical formalism that is better suited to model these kinds of things, namely the π-calculus. This is a well established formalism, developed by a Turing award winner, Robin Milner. i have already built a very successful product using this formalism as the core computational engine. That product was MSFT's BizTalk Process Orchestration. It made MSFT a lot of money. It won most innovative product of the year in 2004, and sparked a whole industry of business process modeling lookalikes. Likewise, as the US Patent Office will show, there's a long history of people using this formalism for distributed computing in commercial products. i know because i hold a lot of those patents.
After we introduce the formalism, we show that the naive model can be translated into a variant of the π-calculus called the applied π-calculus. This is important because that allows us to address the shortcomings of the naive account with respect to the graph evolving as people engage each other in it. It's also important because we have software that turns π-calculus expressions into running code. That's right, the expressions in the paper map directly into distributed, decentralized programs. There are examples in the paper. i can also give you links to such code in github. You can stand up the nodes and run them for yourself. This happens because there's an embedded domain specific language, called SpecialK, that's written as a Scala library. That library is an implementation of a distributed version of the applied π-calculus. If you want to know more about SpecialK, you can read our blog entry as a starting point.(
http://blog.synereo.com/2015/03/17/specialk-kvdb/)
Another reason for using this formalism is because there's a greatly superior notion of contracts built on top of the idea of behavioral types. We've written a lot about that too. You can read our blog entries about that (
http://blog.synereo.com/2015/03/06/social-contracts-pt-ii/) or you can read my ACM paper about contracts and types (
http://openstorage.gunadarma.ac.id/pub/books/Communication-ACM/Oktober-2003/p41-meredith.pdf), or you can go back the source and read Luis Caires' excellent paper about behavior types (
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.9964).
So, what we're saying is not quite gibberish. However, we do recognize that we could always improve our writing, and look forward to constructive criticism about how to improve it. We also recognize that we're writing to a diverse audience with a lot of different backgrounds. That's why there's chapter one, so that people without a background in formal languages or computer science can get the gist of what we're doing. Meanwhile people who do have the maths can read what we're doing and try out the ideas for themselves. Armed with the first part, anyone competent with Scala, or Clojure, or Haskell, or OCaml, or FSharp, or ... could implement a simulation. Armed with the second part, anyone competent with SpecialK/KVDB or JoCaml or a host of other libraries could implement the basics of Synereo on their own.
That's a brief summary of the "gibberish". The rest of the paper is pretty much bog standard. We lay out the business case in terms of the opportunity and the proposed solution. We talk a little bit about the user experience we envision. At the other end, after the technical presentation of the model, we compare the attention model to another model -- from biology -- that can be used to improve signal. We do this out of professional obligation. Just because we've come up with a model doesn't mean it's the only one or the best one. Identifying a potentially competitive model is just good common sense. Likewise we give people a view of our technical stack and its relationship to the existing technological ecosystem. For example, we discuss how we *don't* put everything in the blockchain. Instead, we connect a content delivery network built on top of SpecialK to the blockchain. This makes more architectural sense. It also scales better.
i really hope you'll come to the hangouts and we can talk about the parts you don't understand or would like clarification on. Who knows, maybe you can help us find better ways to express how Synereo works!