I think all .gov needs to use blockchain email so they can't erase e-mail metadata. Not sure if we should be able to read the contents, but by court order it could be revealed (political scandal). Otherwise, just the metadata of time, from, to, etc is on the blockchain. No way to erased e-mails you sent.

I've been saying that about everything related to government. Their phone calls, their sms, their email, office visits, etc.

The thing about government is that no one, not even government can be trusted. Government however, has power. For obvious reasons, no one can govern the government, so all we're left with is improving visibility, heavily.

Absolute power corrupts, and without oversight, they basically have absolute power right now.

does your chain carry all historical data forever? because that will be costly. Do I, as a node, keep copies of emails that weren't sent to me or forum posts that I'm not interested?

interesting! you said in the whitepaper that you can delete history. I need to read further.

Hi Bill,

Yes -- Saito is the first "transient blockchain" and everything will technically fall off the network eventually unless someone acts to preserve it.

It is possible to maintain data on-chain, although in most cases the users sending transactions and the users receiving transactions will not want to pay for that and will prefer bear the burden of archiving them. There is no reason for the entire network to backup my email inbox, for instance. So "permanent storage" will only really be needed for tokens that represent monetary value.

We do have two ways to maintain data on-chain in perpetuity though:

1. applications can manually rebroadcast transactions whenever they near the end of the chain. This is dirt-cheap and helps preserve the security of the network for complicated reasons that you can read up about in our explanation of how Proof-of-Transactions / Proof-of-Relay works.

2. nodes creating new blocks are forced to rebroadcast transactions that meet consensus/code-level criteria qualifying for rebroadcasting (i.e. their "rebroadcast" flag is set and they have enough money to pay for it. We intend this as a fallback rather than the main mechanism -- it will be more expensive.

Generally though, shifting to a transient chain is important as it is one of the steps needed to "fix" the economics of existing consensus mechanisms. It allows us to price the cost of storing a transaction forever by dividing infinity up into manageable chunks during each of which storage costs are accurate and market-driven and fees are handed over to the nodes that are actually doing the work in that point at time.

congrats. I wanted to do this for a long time but I lacked the skills. This is definitely needed

Hey u/trevelyan, any particular reason why the site isn't secured over https?

Hi Jonnie,

There is actually -- see comment blelow -- but if you're concerned about SSL just go through our reverse proxy that adds it. Some links may break:

https://demo.saito.tech

We should have default SSH in the full-node client itself by the time we launch our public testnet in a few months.

Oh the irony in releasing a service that depends on cryptography..

hey craftyguy -- thanks for the reply and for taking a look at Saito. You can access the server over https if you'd like at http://demo.saito.tech (this runs through a reverse proxy that layers on SSH) although this may break some links in our live demo.

The reason the demo defaults to plain http is that the server that feeds out the applications is part of the full-node software and it does not support HTTPS yet. We are intent on fixing this, but it didn't seem like a critical thing to worry about for this dev release, which is focused on getting people a working version that can be run on localhost and give people the tools to build genuinely distributed applications. We hope to get this fixed in the next two months before launching our public testnet and DNS system. Right our biggest dev focus is overhauling the network code for multiclient connections.

With that said, in the long-run it won't matter if users http or https to connect to the blockchain. Saito is not vulnerable to MITM attacks and users can use Diffie-Hellman key exchange mechanisms to swap keys directly over the blockchain. We can think of it as an improved version of TCP/IP that is actually secure but that will cost a few fractions of a cent for every message we need to send to unknown and anonymous peers.

Wow that sounds pretty damn great, I look forward to seeing the dev happen as time rolls. I will always call out non-SSL specifically when discussing all crypto-things but clearly you and the team have thought this out as per your detailed reply. Good luck on the project, I am for sure going to give the demo a test run.

This looks promising and worth keeping an eye on. Good luck with the project!

Seems great, definitely keep us updated!

Cool.This is something new.