Skip to content

Latest commit

 

History

History
94 lines (65 loc) · 3.94 KB

how_does_it_work.md

File metadata and controls

94 lines (65 loc) · 3.94 KB
Raw

How Does It Work?

Here's how FeoBlog accomplishes its core principles (listed in README.md)

#1 Your data should not be held hostage by a single service.

FeoBlog allows your data to be stored on multiple servers simultaneously. It's able to do so via a few enabling features:

  1. The core data structure of FeoBlog is an Item, which is defined in the protobuf file, feoblog.proto. Your blog is just a collection of Items.
  2. Your user ID is a public key used to sign all of your Items. (For more info, see: Crypto.)
  3. The signature for a post (Item) serves as a unique ID for that item.
  4. The server makes all of your Items available via a REST endpoints (described in URL Layout.)

As a result, it is trivial to walk your publicly available data on one server and copy it to another. In fact, the web-based client allows you to specify multiple servers in your profile and sync data between them out of the box.

Because your user ID is a randomly generated cryptographic key, it is globally unique, not just unique to the server that you started out on. You can reuse the same ID on multiple servers.

#2 Your data should be resilient to censorship and server outages.

(See #1). Since your data can be served on multiple servers, if any one of them decides to censor your content, or goes offline, your data can still be accessed on other servers.

You can also run a local server on your computer to act as a backup. Even if all online servers are taken offline, you still have your data and can sync it to a new server.

#3 Your data should not be modifiable by third parties.

(See #1) Since your data is cryptographically signed, readers can verify that it has not been modified since you signed it.

The web-based client in FeoBlog downloads the raw protobuf file and verifies it against its user ID and signature before displaying it to the user. Third-party clients and servers can do the same.

#4 You should be able to create/use clients to view your data as you wish.

(See #1) The same REST APIs that allow you to copy your data elsewhere are usable by anyone to create clients that can download, cache, and present data however they best see fit. (They can also generate signed Item protobufs to send to the server and post on your behalf.)

There's an example client written in Python available as an example here: https://github.com/NfNitLoop/fb-rss

In fact, the built-in web client (available at /client/) uses that same REST API to view and post data. Your own client can do everything the web site can.

#5 [Servers] should be able to block content

One problem with blockchain-based approaches (like Scuttlebutt) is that if any piece of the blockchain is missing, the data structure is broken. (Or, at least, no longer verifiable).

Since FeoBlog is organized as a collection of signed Items, any one item can be omitted from the collection by a particular server.

This could be due to legal reasons (ex: a DMCA takedown request) or just due to the fact that the server administrators find the content objectionable. This could also be due to a user exceeding their quota on a particular server.

In theory, DAG metadata could be added to allow easier detection of this kind of censorship. (See: #30.) However, censorship would already be exposed during inter-server sync, so I'm not sure that feature is currently necessary.