Jump to: navigation, search

Misc Ideas For 3.0

Revision as of 23:21, 8 June 2014 by Indolering (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Anything that isn't large enough to justify it's own article.

Prefix for Non-Standard Fields

It seems as if *every* spec eventually adopts a special quantifier for custom fields. Without it, people just make their own custom fields but without any special signifiers. This is harmless until the official spec feels like adopting it with some changes and then they have to come up with a slightly different name and you get the spaghetti mess that is Javascript. However, an official signifier allows for experimentation and eventual adoption without breakage, fragmentation, or a messy namespace.

HTML 5 (finally) enabled this formally using the 'data-' for attributes on HTML tags. Dashes are allowed in JSON but they are not allowed as variables in Javascript and many other languages. _ and $ can be use for variable names in Javascript but _ is dangerous as it is used by many programming languages for meta functions (and it isn't allowed in CouchDB so it would make my life a PITA ;-) ) HOWEVER $ signifies special variables everywhere...

 "$registrar" : "registrar-name.com" 

Version Field

Theoretically speaking, we don't need to worry about versioning because most of the domains will be refreshed once a year. However, with multi-year renewals, a version number might be a good idea.

 "v" : "2.5" 

Ultimately we must make the price of harvesting hidden entry points (as detailed in the HTTP proposal above) scale linearly. The simplest way to do this is to require a donation, however small.

"name" : "wikileaks",
"donate" : "NDtPuyg3adscr6HCE1GUiSsKPtA8ewKgz3"

I placed this proposal in ideas for 3.0 because we need to work out the exact mechanisms for tracking which clients have donated funds. Preferably, there would be some sort of deterministic way of handling things so that no accounts would have to be tracked.

Many have suggested various proof of work schemes in the past using Javascript. This might require some sort of proof-of-work field which outlines the algorithm to be used and the difficulty could be adjusted according to the trustworthiness of the requester.

The main problem with such proposals is that they do not scale well for clients. While the government could afford to pay for a small cluster, we can raise the time and energy required to (at most) a few seconds for each client. When it comes to smart phones, etc, the cost must be logarithmic for legitimate users and linear for censors.

What's hilarious about this proposal is that while users only have to pay once, the censors have to basically fund their opposition. One can even imagine using Bayesian analysis to raise the price on suspected bots but subsidize the price of high-scoring users. One can even model it using Big-O notation and "prove" that we will win. ツ