View source for Dailycoin powered pastebin spec

== Dailycoin text paste site tech spec, version 1 ==

The site is hosted on e.g. nearlyfreespeech.net and can be backed by flat markdown files in some directory (or records in an SQL database if that's preferred). No need to scale beyond a few thousand users -- that would be a massive success already and then we can reimplement it in a scalable way.

The site is a collection of immutable and anonymously submitted text pages (a la pastebin) which are interpreted as markdown documents.

The submitter will send the contents and the page name, using a form similar to the one in pastebin.com, which must be unique and probably be sanitized (no spaces or weird symbols, is used as the filename for storage too), and then it will be hosted "forever" on the site (as long as it can pay for its own hosting)

I guess everything can be done with some combination of client-side javascript and PHP.

There are no user accounts. There is no need for sessions or for authentication whatsoever.

=== Page balances ===

The site keeps track of two integer variables for each page (in a DB or another flat file with the same name as the page but with an e.g. "dat" extension instead of "md"), where "1" means 0.0001 XDL balance deposited into each one of these two budgets for the page:

* General balance
* Storage balance

Pages incur a storage charge of, say, 0.0001 XDL per kilobyte per day. Storage charges are subtracted from the general balance first, and then from the storage balance. If a page can't pay for storage at the time it is billed, it is destroyed.

When pages are accessed (read), they are billed at, say, 0.0001 XDL per kilobyte transferred (probably make this less expensive...), from their bandwidth balance. A page without a positive bandwidth balance will not be served until the balance is topped up (the website says something like "sorry, you have to fund this page").

=== Funding a page ===

Transfer any amount of XDL to a specific contract address on the Worbli network, with a memo field that is either "pagename" (sending 90% to the general balance and 10% to the storage balance of "pagename") or "pagename number" (sending "number" to the storage balance and the rest to the bandwidth balance).

Transfers are absolutely anonymous, one-way, irreversible, non-refundable, and there are absolutely no warranties or any level of service guarantee. The maximum accepted deposit value per transaction is 1 XDL.

Deposits never fail by definition. If you fund a page that doesn't exist yet, someone else can create a page with that name, and it will use your deposit.

Transfers are monitored by an external process that listens to a blockchain API / service (which I will pay for; this will not be expensive). That external process is notified of deposits, and it calls the website with special (secret) credentials to tell the website to increase the balances. The website itself doesn't know about blockchain; it only knows about the balance data files of each hosted page.

=== Billing logic ===

The billing process/logic somehow runs on the same node that hosts the website. It probably makes sense to run all the billing, including storage billing, whenever a page is accessed, to avoid an extra process that has to be scanning all pages all the time to bill for storage. To clean up expired pages before they are accessed, we can manually run a script on the website host node (ssh) that will purge anything that's needed whenever we feel like freeing up space. We can do that script later.

On the server side, each access to a given hosted page is considered to consume bandwidth equivalent to the size of the markdown file that backs it. 

=== Business model ===

Technically, it's easier to just consider all deposits as spent and as belonging to the business. They can't be withdrawn because there is no concept of user, it's entirely anonymous.

The upside is that there's now an entire class of funds/balances tracking errors that disappear. ALL of the XDL deposited can be considered as paid to the business already.

XDL can only be ever sold from the site wallet to cover for business operation and development costs.

10% of all XDL deposited is burned (helping deflate XDL).

If the site shuts down, all XDL that's still in it will be burned.

=== Spam limits ===

Integrate a google captcha on paste submission.

All pastes receive 0.0001 XDL of default credit so they can be used for a while before they are funded

Paste max size: 64 KB.

== Version 2 ==

When creating a page, add a checkbox for "make contents mutable."

If the page is mutable, then an additional form field appears where you can enter a password. It is pre-filled with a good password.

Now you can actually resubmit a paste on top of a page that already exists by specifying the same password that was given during its previous creation.

You can change the password by resubmitting the exact same page with the old password, and specifying a new password.

Each page now has an additional data file / field associate with it, which is its optional password for overwrite.

== Next gen ==

If this is ever actually successful

* Support logged-in users & user balances
* API for users
* No captcha for logged-in users
* Actually scalable website & backend
* Logged-in users pay to view pages when they access them and the page has no General (i.e. bandwidth) balance

== V1 To-do list ==

Release as one feature-complete Dailycoin dapp -- an example; and follow it up with the Mediawiki Dailycoin integration ("gen 3" below)

* Hourly cron job at the web server to charge storage fees from pages that have a balance below a threshold, and to purge all pages that are broke and didn't pay up (specifically tuned to get rid of spam pages that are never funded, or that receive minuscule funding)
* Minimalist layout (content pages are only the content)
* Add hit counter that is incremented in view.php (and in download.php)
* Download.php will make browser prompt for downloading a page-file instead of displaying it (contrast with view.php)
* Status.php query script (ask for the status of a page, if it exists or not, and then display stats like balances, hits, byte size, creation/access date, content-type)
* Deposit.php that receives deposits from external bot
* Deposit bot that calls Deposit.php (centralizes all logic that prevents double deposits -- uses status queries to check that everything is OK with the deposit)
* Perhaps add a "deposit #" to the bal-db file that can also be queried by the status
* Recent pastes list on the front page (e.g. last 20). use 2 flat files of (paste name, date), append-only file mode, delete file when the other fills up 
* Pastes funded last 24 hours (e.g. top 20), keep a flat file with a list of all pastes funded in the last 24 hours: paste name, fund date, fund amount (total). when re-funding a paste that's already in the list, KEEP the same fund date and ADD to the fund amount. a paste is removed from the list (when the list is rewritten) if it has expired (>24h). a paste is added to the list if it is in the top 40 by funding, ignoring all pastes that expire before it. file is read and, if appropriate, rewritten by the Deposit.php deposit logic
* default content-type of response is text/plain UTF8 encoding
* .md extension and content-type in response
* .html, .htm extensions return raw HTML content
* jpeg, jpg, gif, png extension and content-type in response
* add & test caching logic (given that content is immutable anyways, should cache at the client)
* .js extension will return a (I guess) blank HTML page with a <script> </script> tag whose contents are sourced from the file
* upload local file from a client-side file picker instead of pasting content in a box

== Earlier idea draft ==

simplest version:

Create a wiki that allows anyone to edit and host content, but each individual page has its own dailycoin budget.

All pages have separate storage and bandwidth budgets.

When a page is served, its bandwidth budget is subtracted. A page with a budget of zero is not served.

A page's storage budget is subtracted over time (i.e. bytes/day hosting) and when that runs out, it start subtracting from the bandwidth budget. When both budgets expire, the page is deleted.

All pages can receive dailycoin deposits.

Pages cannot be edited once created since there are no user identities.

The interface is minimalistic / light-weight, inspired by Medium. 

better version:

Introduce user accounts.

Pages can, by default, only be edited by the user that created them.

User accounts can receive deposits, and the user can fund pages within the system so that individual page funding doesn't involve blockchain transactions (i.e. the site is prepaid and has custody of all XDL funds deposited on every user account)

Users can give permission for other users to edit their pages.

Users are given a root path /username to post, so that all pages under that path belong to them (it looks like the git hierarchy)

== Third generation, may be leapfrogged into ==

Use MediaWiki as the base.

Manually approve users (e.g. must be dailycoin users). So there is no spam problem.

All pages that are created belong to their creators (locked, by default, from edits by others), and are billed (storage and networking/accesses) against the creator's account balance of deposited XDL.

Pages don't need to be auto-deleted. They can just accrue a negative storage balance. If they really must be purged to save hosting dollars, I can do that in the shell, manually.