Difference between revisions of "Dailycoin powered pastebin spec"

From Democratic Money wiki
Line 67: Line 67:
  
 
Each page now has an additional data file / field associate with it, which is its optional password for overwrite.
 
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

Revision as of 17:34, 21 June 2020

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

90% of all XDL consumed by storage or bandwidth charges is sent to the business. It is only sold to pay for the hosting of the system and to fund development.

The business does not sell or transfer XDL to pay profits to anybody. The business itself is non-capitalist, i.e. profit-free.

10% of all XDL consumed by storage or bandwidth charges 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