..... but first, we have to normalize the project a bit and get the basics right in order to create optimum leverage for the technology.

on tau, advanced users define languages, and normal users use (speak) those languages.
to define languages one needs to know to define a context free grammar (the syntax part) and then to write logical formulas that express which relations are implied from derivation trees (the semantics part).
any knowledge about how compilers are built can be useful.

it is all about formal languages. the platform is not intended to support natural languages

good and important question, and could be very relevant for the old tau, but irrelevant for the new tau.
the new tau features what i refer to as "the internet of languages", a platform to define formal languages (by formally defining their syntax and semantics) with tools allowing semantics-preserving translation between defined languages, and more.
the infrastructure of the new tau, is a mechanism to define and connect languages.
so (almost?) any ontology or framework will be programmable on tau, with or without connecting it to more languages.

Great to see everything is quiet again around here  

If Tau is ready - someday, when it is ready - I presume the work only begins. As a community. What is a smart roadmap to:
1) Get educated in the right fields to be able to use/program Tau? What should neccesarily be learned already?
2) How to get some experience, before Tau's ready, that is useful? What language? Or knowledge? Or skills?

Basically: What's is relevant to have done to be prepared once this network is up and running and Tau needs some serious usecases and testing?

I can try to give you an analogy. Let's take cargo ships for instance.

Generalist ships can carry stuff of all shape and form with no restriction other than their size and weight limits: space rockets, airplanes, cranes, train wagons, whatever. It's cool because you can really carry anything. But it comes with its own difficulties: it's pretty much impossible to plan in advance how exactly you are going to arrange the things you need to load so that they will fit neatly and optimally and won't move during the trip. Sometimes your guys at the dock will manage to find a solution quick. Sometimes they'll have to load and unload things so many times that it seems like it takes forever. And that's when you don't have someone asking you to ship something so enormous that it blocks your docks for a week when you figure how to ship it at all. This type of ship is turing complete. In theory it could ship the moon. It could ship anything of any size if you have an infinitely large ship, and infinite number of dockers and an infinite amount of time. But in practice that doesn't really work like that, and the actual ships that end ups being used are all limited in size, and your docks have only that many cranes and that many dockers to help. Those ships are a watered down finite version of the real thing. So what happens with the real-life finite turing ships is that they work ok until it don't. And you can't really tell in advance when things are going to be smooth at the dock or when it will become really messy because the only way to decide how things gonna fit and what ship to use is to try to fit them in the ships. Of course there are many trivial shipments but the problem is you have no guarantees that a shipment will be easy to handle, difficult or downright impossible. But that's not the worse thing: the nightmare of turing-complete shippers is the outsourcing business, that is to say when another shipping company asks them to ship the cargo of their clients who may themselves be shipping companies outsourcing for other shipping companies and so on. Since they are all in the same business of turing-complete shipping as you are, they can't tell what the size of their cargo will be, and their clients don't know either etc. And if you yourself start to outsource unknowingly to one of the clients of one of your own client, that's where things start becoming self-referent and in some cases paradoxal, leading to capacity planning decisions that are sometime inconsistent.

Some other ships are specialized in carrying containers. They can carry only containers, and all the containers need to have exactly the same dimensions. No exception allowed. The containers are spacious, and inside the containers you can arrange things the way you want so it's not a problem for a large majority of the typical use cases. This type of ships is called total functional ships. The advantage is that even a 10-year-old could tell you just how many containers you can load on your ship if you give him the dimensions of the deck and the height limit so it's really easy to make sure that you always have the exact right capacity for your cargo, and your dock is working in continuous streaming loading container after container and ship after ship 24/7. But the problem is that you just can't carry anything larger than a container, making the shipping solution non-complete. Well, in fact there is a little secret: with some coordination you can carry anything of any size, but you'll need your customers to be smart and figure a way to breakdown the cargo into components that can fit in a container. You'll still be able to ship a plane, a rocket, the moon or even the whole infinite universe, but it will all have to be done in small parts, chunks and/or raw materials, that you will reassemble on the other end, effectively recovering the full expressiveness of what turing-complete ships are able to do, but over a controlled sequence of individual containers possibly carried by an infinity of ships. That requires a lot more thinking and engineering ahead of time than just shipping things piecemeal, but the reward is that at least at the time the cargo arrives at the dock, you don't have to worry that it could be too big to handle, and there is always a solution to the questions of how to load the cargo and how long it will take to your dockers to do the job. Like in the case of turing-complete shippers, you can also handle the outsourcing business of other containers shippers and outsource yourself, but since everybody can forecast what they are going to ship because nobody accepts cargo that's not already been quantified, it's impossible in the total functional shipping business to get requirements like "I will ship through you what is being shipped through me" but rather requirements like "I will ship 159 containers". This forced determination in relationships prevents the occurrence of self-referent cargo and guarantees that capacity planning leads to results that are always consistent.

In this analogy, Tau-Chain is a container ship company and Ethereum a generalist ship company.

Tau-chain can tell to its client how much their cargo will cost to ship, how long its gonna take and when a single ship isn't enough and will use all and any container ship available of any size regardless and manage to dispatch all the cargo optimally. It can make all sorts of predictions on the shipping like checking that weight is well balanced, or that temperature in the containers remains within a certain range etc. Clients can attach to containers  fast automated procedures called proofs which took them quite some time to prepare but that will allow to clear automatically and very fast custom, security, and quality controls at the arrival point so that the cargo can be deployed right away to its intended use and used on the spot. Another interesting aspect of Tau-chain is that it finds its container system (Tau) so good that the company decided to eat its own dog food and sequence itself in a continuously evolving series of its own containers with custom procedures to maintain its own integrity as it evolves.

Ethereum on the other hand can't quite tell in advance just how big a ship will be needed for any specific cargo nor if it will fit at all in any ship, so what it does is to let the client decide themselves what size of ship they want to use (the client would typically simulate a dock in his backyard to try to predict what volume his cargo could take) and make them pay for the service in advance. When the cargo arrives at the dock, if it fits in the planned ship Ethereum sends the ship even if it's not full. And if the cargo doesn't fit, it's just thrown in the sea. Either way they keep the money. Cargo doesn't come with any sort of automated clearance test, so it's up to their intended users to figure if the cargo is correct and have it pass all clearance tests before they can use it safely (which is never entirely certain as the case of the DAO has shown).

I hope this analogy helps making these computing paradigms less abstract. There are many approximations and concepts that I had to stretch to makes them work with the analogy and are not really exact but that should give a rough idea of the differences, and how these affect the distributed computers that implement them.

Cargo doesn't come with any sort of automated clearance test, so it's up to their intended users to figure if the cargo is correct and have it pass all clearance tests before they can use it safely (which is never entirely certain as the case of the DAO has shown).

great idea! but can come in addition, not instead, because some people want to move between their own wallets from time to time.
we can set that when the final coins will be ready, addresses that hold the tokens, will get more coins, according to the so-called "coin days".
the numbers are obvious: we'll do it relatively to the 15% discount.
so, another way to get the 15% discount, is simply not to move your tokens from the 1st of march which is about two weeks from now (this doesn't hold for tokens held on bittrex). i'll write it publicly somewhere.

Hai,

heb de api even uitgetest en bij mij werkt de qrcode niet goed, als ik deze scan vanuit, bijv de blockchain app, dan gebeurt er niks.
scan ik het gewoon vanuit een andere app dan staat er alleen maar dit: bitcoin:?amount=&label=

gr roland.

You're wrong, but I don't have the time to explain why.