don't want to spend too much time fussing over this preliminary announcement, and spend more energy instead on actually specifying and implementing, but I needed a name to pin it to.

I wracked my brain to think of an original name that conveyed the core principle at the heart of what I believe Steem is about, and I eventually came up with DIV, as in, a share, or part of a pool.

It wasn't already taken!

I have been busy today wrestling with Inkscape to design a logo, as you can see it has lots of elements related to what it is about, the pool distribution, the up and down votes, the word DIV is encoded in the shapes, and it sorta has a face and/or butterfly sorta shape in there somehow too. It's not a final design, I will make it much prettier by the time I am done, but it might yet be finished. There is no curves except the circle, which I am not sure I like, but I'm all spent fiddling with it for now. It can be fixed later.

The gitlab repository lives here: https://gitlab.com/steempunks/div under a new group category I created called steempunks, which is a group intended to be a way for us malcontents tired of watching this beautiful concept turned into a self voting, attention whoring bunch of morons who don't value real integrity, have any morals, or for that matter, any respect for long established rules of computer systems architecture and programming.

The chat for this projects is a new Discord server called 'steempunks'. To join, click here: https://discord.gg/AmyB6ee

In Brief

DIV takes all the things that make Steem such a compelling platform, and replaces all the parts that are missing, or destroy its value, and puts much better ideas in their place, from the ground, up.

Steem is built on a very weak foundation, with too many self-contradictory elements. Div will have repeated motifs that you will see as I flesh out the architecture and protocols.

• Every provider of service to the Div network, gets paid a share of the administrative pool
• The data stores are isolated by datatype, and not agglomerated into a single blockchain
• There is no blockchain, the databases synchronise directly with each other (and this is simple because the databases are simple), as well as via periodic broadcasts from validator nodes.
• Validators are elected as in Steem, but active validators votes are discounted, and their vote power stake applies to their own witness in the calculation, and no other votes are collated
• Validator nodes have 5 distinct subsets, based on 4 global regions and a 5th central cluster that acts as a second-tier of validation to broadcast georegion transactions to the other three, ensuring that no attempt has been made to fork the chain. Each Georegion has a set of 5 validators as well as 5 for the global.
• Validators use a gossip protocol to immediately validate transactions, and periodically each node sends their list of last x number of transactions and all nodes clean up their latest transactions such that only those with a minimum of 20 out of 25 must be found in the transactions. This allowance for error covers the potential for temporary communication problems as well as nodes being offline, while being more stringent than any other 'blockchain' in forcing coherence so rapidly in the data set.
• Client nodes must send out their transactions to each of the 5 validators in their georegion, and if this list has changed, the client will receive the correct list from the nodes that were correct, and the transaction must be rebroadcast.
• Once a geocluster approves a transaction, each of the 5 validators then pushes the update to two replicator peers (RPC nodes), randomly selected, who repeat this propagation, and each replicator then will continue to listen for more nodes to send the identical transaction, and then flip a switch once 4/5ths of received messages out of the list of cluster members are identical, and stop transmitting the transaction they received, or, change it if they discover they were first infected with the incorrect message. This is called 'epidemic propagation' and minimises the amount of message cycles required for complete propagation.
• In addition, there is 'full archive' nodes whose specialisation is to store long term loogs of ordered transactions. To facilitate this, every node uses an Interval Tree Clock timestamp system, which allows, through a process of cross-checking and re-ordering, similar to how Git clears up ordering conflicts. These archivist nodes are employed by replicators (RPC nodes) when their database has had necessary data to a query response pruned.
• Validators do not keep a full log of the transaction history, only enough to ensure at least 5 preceding transactions in a sequence are available, sufficient for verification, but economic so that the transactions can be processed quickly. Likewise, validators can use Archives to validate transactions in the event they do not have 100% of the leading edge of 5 transactions.
• Accounts are not able to vote on their own posts, this is implied and embodied in the fact that they receive the largest share of the curation payment, by default. In other words, both Validators and Users automatically vote on their own posts and validator nodes. By simply announcing intent to run for election as a validator, one's vote is based on one's Stake, the name of the deposit instrument
• The base currency is the Div. Unlike Steem, there is no secondary abstract VEST currency, because Div will not have a hedged instrument like SBD, as I believe it does not benefit the platform. Div is issued at a flat rate of 5%, which is produced via an inverse square differential formula that means that every day, the amount of new Divs issued, is 5% of all issued to date, and the pool size will be adjusted to maintain as close as possible to a precise 5% of supply per year.
• Div tokens are refractory tokens, that cannot be split, and to create change operations, the Stake of other users, who have no vote, transfer, or other transactions aside from change operations, are randomly selected to provide the change operation. Payments are provided in a power of two sequence where the total amount is divided by two, and one half is divided by two, until there is 8 separate denominations. This provides for a very simple, directly binary based currency. Change operations will be rare, but when they happen, the change provider gets a payment of 5% commission for the operation, which is expanded by 5% in order to facilitate it. Thus, holding Stake entitles a user to earning tokens by providing change from their account (The Validators are empowered by the Stake smart contract to shift the necessary change tokens out, and the larger token plus a 5% change provision payment.
• Divs are refractory, because by making each individual token an unbreakable unit, it is only necessary to keep 3-7 past owners stored in a validator's database to ensure they are not being improperly transferred by other than the current true owner. Thus the immutable record need only remain available in archive server's database.
• Replicator nodes provide query results always through a chain of 5 intermediary nodes, who sign the outbound results, with the signed query from the user making the query, and based on this, the provider then submits a payment claim to the validators based on this certification of service provision. Replicators involved in this periodically repeat the same query to other nodes, and if they find a discrepancy in the results, they then submit a complaint report to the validators, who will then strike the payment for service to an Replicator for a payment, and a tally is kept of Replicators who produce nondeterministic results.
• The same basic model is used to monetise nodes providing hosting for media uploaded by users that attaches to posts, such as videos, photographs, and the like. These media are identifiable by their unique hash, like IPFS and Bittorrent, and relayed via proxy through other hosting nodes, who certify the servicec, and then submit their claim to the validators, who thten assess the claim and issue a payment for hosting services rendered. I haven't worked out the exact protocol for validating this activity, so it cannot be gamed, but it will be similar to the RPC service, and, eventually, it is intended that this type of hosting service can include hosting an application database.
• There is no such thing as 'Smart Contracts' in Div. These can be implemented by the above mentioned sub-application databases, Database-as-Content's verification system, using a similar secure messaging protocol that ensures thtat the data is not doctored in transit, and will be periodically also double checked, if a claim for payment is to be made. This also allows an application to instead be trusted by the creators of the hosts replicating the service, through an agreement outside the chain. If the creators receive complaints of poor service, the complaint can be forensically investigated, as, in specific cases, especially, one cannot use complex transit paths via non-simple-routing nodes, due to latency requirements (eg, FPS multiplayer games).

It turned out to be longer than I had planned, but I will just point out that the rollout of the service will be phasic, the first goal is to entirely replace Steem's service with Div, including Replicator service monetisation (as it is a necessary but missing part of Steem), however, the monetisation of Database-as-Content, is for post 1.0.

Unlike Steem, also, once the system is fully operational and all known bugs in the implementation of the specified features are squashed, it goes to a full 1.0 release and thereafter is on a schedule of Hardforks, where one change at a time may be submitted per month, voted upon to be included by all interested parties in the system, the winning proposal then becomes the HF subject, and election by implementation on the date of the Hard Fork, once a month, on the 5th day.

A 'Database-as-Content' service that will also be high priority, is that the codebase of the Div servers will be itself hosted on the servers themselves. All of them, yes. When a hardfork is scheduled, the tagged altered/additional code, will be compiled automatically at the command of the node operator through a control interface. The codebase itself will function like regular posts, and each edit will be eligible to be voted upon and a payout will come after the code makes it into the hardfork it relates to, according to the stake that votes on it. This automatically enables developers to be directly compensated for their work once their work has been agreed to be worth paying for.

This is of course a later project to the obsoleting of Steem, but it is, alongside monetising hosting content as the two top priorities once the system is online and functional.

Funding Model

There will be no 'investing' in the development of Div, as in ICO, or any other such contract. I am funding myself, and anyone who wants to contribute, also will be funding themselves, putting our money, as well as our sweat equity, where our mouth is, and thus by this, the simple fact that we will be amongst those who acquire the first few months of token issue, in a position to profit more than any other later users. So, if you want to help, you must sacrifice, like I am.

I was considering trying to use a name that more strongly highlighted this aspect of sacrifice, but I think Div comes close enough. I base this on the Maxim of Equity:

Sacrifice is the measure of value