# Decentral Web

## Public Key Cryptography

In hotels every room has a different lock but there is a master key that can open them all.

Public key cryptography works the other way round:

• there is just one sort of lock
• all keys work in all locks.

## Keys

• Keys come in pairs.
• If you lock with one key, then only the other key will unlock it.
• You can't tell by looking at a key what its paired key would look like.
• You can't tell if two keys are paired by looking at them: you have to try them.

## Locking

You can lock a lock two (or more) times, for instance, first with one key and then with another.

To unlock, you have to first unlock with the matched key of the second, and then with the matched key of the first.

## Public and Private Keys

Everyone is given a matched pair of keys, and one is made public: anyone can have a copy of it.

The other is private: only the owner may use it.

## Digital Signature

I write a message and lock it with my private key.

Then I send it you with the label "From Steven". You know from this that I have locked it with my private key.

So you get a copy of my public key, and try to unlock it. If it opens, then you know for sure that it really is from me, since only I have a copy of my private key.

## Digital Privacy

I write a message, and lock it with your public key, and send it to you with the label "To You".

I can be sure that no one else can open it, since no one else has your private key. Only you can read the message.

## Combined: Secure messages

Now I can combine both things:

• I write a message,
• lock it first with my private key,
• lock it with your public key,
• label it "From Steven, to You".

I am guaranteed that no one else will read it, and you are guaranteed that it really is from me.

Secure messages.

## Reality

In reality the keys are mathematical formulas and numbers, but the principle is the same:

• There are matched pairs of (very large) numbers that are used as parameters to the mathematical formulas.
• One of the numbers anyone may know, and the other you keep secret, and only you may use.
• If I encode a message with my private number, you can decode it with my public number and vice versa.

When you use https: to a web site, for instance with your bank, all communications are encrypted with a single key system, but which key to use is decided with a public key system first.

## Advantages: for example, credit cards

I order something from a shop by sending a secure message to them. I know that only the shop will read it, and the shop knows it really is from me.

Instead of giving them my credit card number, I give them my credit card number locked with my private key, and the bank's public key. So the shop doesn't know what my credit card number is, but they can send it on to the bank; only the bank can read it, and the bank knows that it really is from me.

So the only people who know what my credit card number is are me and my bank.

In fact, there is no reason to have credit card numbers at all in this system because I can lock the message "Please pay this shop €20" and the bank knows it is from me.

The shop doesn't even need to know my address, for similar reasons.

It would also be perfect for dealing with Spam email: you would know if a mail really was from your bank; and it would increase privacy, because you are assured that only the recipient can read the mail.

I could try to log in to a site. I say "Hi, I'm Steven"

The site says "Oh yeah? Here is a message encrypted with your public key; tell me what it says." (Or it could say "Here's a random message. Encrypt that for me"; makes no difference.)

My browser decrypts it with my private key, and I'm in, without having typed a password.

Of course your private key is your crown jewel. If anyone gets their hands on it, you are in trouble.

## Social

It allows you to

• record things,
• say who your friends are,
• say who can look at which of your recorded things,
• Iook at what your friends have recorded.

The only player you can't stop from looking at all your data is Facebook itself, who owns all the data, and uses it to work out things about you.

## How to do Facebook decentralised

• Store locally who your friends are, along with their public keys.

Your system knows who can see what, and only shows your stuff to people who are allowed.

You (and they) have an aggregation program (locally) which goes to each friend's store and gets their latest stuff, and displays it to you.

Different people could have different aggregation programs that do different things.

## HTTP

HTTP, the protocol used for serving Web pages, has served us well for the last 25 years, but is beginning to show its age: it has become a single-point-of-failure for content.

## HTTP

• Client-server
• Simple to implement
• Served us well all these years.

BUT

• Central point of failure
• Allows for DDoS Attacks
• Allows governments to monitor, block and close sites
• Popular sites have to use load sharing
• Peaks of demand can easily crash sites or make them unavailable
• URLs keep changing!

## How could we do better?

Peer-to-peer:

• Harder to block
• The more popular particular content becomes, the easier it is to find
• Even if the originating site is offline, the content may still be available
• Peaks of demand are automatically dealt with
• Popular sites don't need wide pipes.

Saying not where to get it, but what you want

Fall-back to single source for long-tail content.

```magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
?as=http%3A%2F%2Fexample.com%2Fulysses.html```

## Bit Torrent

If several people have it, they can share the task by sharing different parts.

You get it even faster!

## Tribler

Note (in blue progress bar) how the file is loading in bits, but priority has been given to the start of the file so you can immediately start streaming.

## Why this is good

Although you still need HTTP for long-tail, and single-use/personalised content, replacing HTTP with peer-to-peer+magnet links makes the most of the web:

• Harder to block and censor
• Faster
• Cheaper for web sites
• Increased availability
• Resilient to peaks of demand
• You can phase it in without disruption to the web.
• You can still merge the personalisation with common templates.

## Conclusion

The Web was designed as a decentralised information system.

Slowly it has become more and more centralised.

It doesn't have to be though: there are still things we can do to make it better.