Peergos - posts

2025 - What a year!

2025-12-27T00:00:00Z

What a year.

In 2025, we shipped 20 releases, more than double last year's 8 all with substantial features and fixes. We did this with an extremely small team and along the way we tripled our number of paying customers.

We don't have investors. We don't take Venture Capital. Peergos is a non-profit funded directly by the people who use it, customers and donations, which keeps us focused on building what users actually need. If you value a privacy-first, lock-in-free humane web, you can support our work by creating an account.

Version 1.0 and Major features
This year marked a major milestone: Peergos 1.0

Alongside it, we shipped:

Native desktop apps (Windows, macOS, Linux)
A full-featured Android app
A high-performance sync engine
Post-quantum secure sharing
Easy server migration
Massive performance improvements across the filesystem and p2p stack

Let's hear more about each of these.

Sync: Fast, secure and bandwidth-efficient
Our biggest new feature this year was the sync engine, now available in the desktop and Android apps. It lets you:

Keep a local folder fully in sync with a folder in Peergos
Sync multiple devices to the same remote folder
Choose whether deletes propagate (turning sync into a backup)

It is efficient, so that if you have a big file synced and you modify a small section of it then it will only upload the modified chunk(s). To enable this and reduce bandwidth required in other situations we added some new encrypted metadata to files - a tree hash. For now this is a custom tree hash based on sha256, in the future we will switch to blake3 once browser support is better. This tree hash allows us to efficiently determine if a local and remote file are the same and also to detect which chunks changed between two versions of a file.

Security by design
The sync engine operates on a write capability limited to the synced folder. Even if a device is compromised, no other Peergos data is exposed.

On Android, sync runs without the dangerous MANAGE_EXTERNAL_STORAGE permission. Instead, we use the modern Storage Access Framework, giving users fine-grained control without sacrificing full bi-directional sync of any file type.

Native Desktop apps (no Java required)
We released native installers for Windows, macOS and Linux:

https://peergos.org/download

This removes the need for Java and enables deeper system integration, including sync. It also improves the threat model: a compromised server cannot deliver a compromised client unlike a web app.

Each platform had its own challenges: Windows CLI needing a separate binary, MacOS signing and notarization, Linux portability, but the result is a cleaner, safer and more capable desktop experience.

Android
The Android app has been our most popular addition. You can install it from Google play or side-loading. It supports the full user interface plus bi-directional sync. Next year we'll be integrating it with the native Android filesystem allowing you to send files directly between Peergos and other apps.

Post quantum
We've upgraded sharing in Peergos to use a hybrid key-exchange based on Curve25519 and MLKEM-1024. This means that anything you share in Peergos is safe against a harvest now, decrypt later attack from a future large-scale quantum computer.

50-150x Faster folder loading
Previously, loading a folder in Peergos required listing all the child capabilities and then retrieving the metadata for each child before anything could be shown in the UI. We introduced a bulk champ.get call which allows us to retrieve up to 20 children in a single request. Then we added more metadata to the directory entries, specifically the mimetype, creation date and whether it is a directory. This means we can populate the UI as soon as we have listed the capabilities and update it with thumbnails and modification times asynchronously in the background. This last change made the UI about 100x faster on high latency connections. Now we can load a folder with 25,000 children from a server on another continent in 29s.

We can still improve this further in the future by parallelising listing the directory capabilities, which currently need (number of children)/500 requests in series. By using the same "stream-secret" technique we use to enable zero I/O seeking within huge files we can make all those requests in parallel and thus only a single roundtrip to the server, regardless of directory size.

Towards a CRDT
We now have automatic concurrent modification handling in most circumstances. Previously, if you uploaded a file whilst editing a totally unrelated file, then saving the changes would result in a concurrent modification exception from the server. Now we handle these automatically if there isn't a genuine conflict, i.e. a concurrent change to the same file or dir. In the future we will also handle non conflicting changes to the same dir. The plan for files is to support CRDT formats like automerge which can automatically merge in concurrent changes.

Shared page
There is a new shared page available in the left sidebar which shows all the things you have shared with others, making permissions and visibility much easier to manage.

Built-in migration and mirroring support
Peergos was designed from day one to avoid lock-in.

Your identity, data and social graph are portable.

This year we made it incredibly easy to mirror your data on another server or migrate to it. With a few clicks you can request or pay for space on another server to start mirroring your data or completely migrate there.

Quic
As part of a grant early in the year, we implemented the quic secure transport upstream in jvm-libp2p. This is now enabled in Peergos and improves reachability of nodes and also resolution and speed of the DHT.

P2P improvements
We fixed some bugs in the p2p http request implementation which makes them much more reliable now. We have also removed all usage of bitswap for retrieving blocks - we just use a standard p2p http request.

Server-side scalability
We've done a lot of work on speed and scalability of garbage collection on large blockstores. Now a garbage collection on a 10 TiB remote S3 blockstore can run in under an hour. We are currently working on another huge speed up to this by segregating the blockstore by user.

The rest
We've added translation for French, Spanish and Polish. There have also been lots of fixes, new mimetype support and CLI improvements.

Looking ahead
2025 was about native apps, ecurity and performance.

2026 will be about polish, usability, iOS and deeper OS integration, while staying true to our principles: privacy, portability and user control.

If that resonates with you, create an account or support our work and help shape what comes next.

Here’s to an even better 2026.

Decentralization Matters

2025-07-14T00:00:00+01:00

Have you ever invested time and energy into using a digital service and noticed that it gets worse as time goes on? Maybe the provider added some useless AI integration or started feeding all your data into an AI against your will. Maybe they introduced ads or made it worse some other way. You're not alone in these experiences - in tech, the process is ubiquitous, and gained the name enshittification. It is an example of companies acting against the interests of their users.

End-to-end encryption (E2EE) helps with some of these problems, but leaves others unsolved. E2EE is designed to protect you from the service reading your content, but that is not the only threat people need protection from. The real issue isn’t just privacy - it’s power. Who controls your digital life?

Most tech companies turn bad eventually. This can happen in many ways, but it always eventually happens if the right balancing incentives are not in place. They can be sold to private equity, their investors can demand an exit or push for growth at all costs. The company could be infiltrated by intelligence services. They can simply grow too big and turn evil, or the markets could change, leaving the company bankrupt. Or perhaps more than one of these at once! The question isn't if a company will betray you, but when - and, most importantly, what can you do about it.

Digital feudalism vs digital citizenship

The problem lies at the core design of the service. If it is centralized (i.e., there is only one provider), then your choices are either to stop using the service entirely, or to put up and shut up; naturally, neither of these are good options. If you cannot easily switch provider of a service then you are locked in. When you are locked-in, you are vulnerable to the following consequences: - Arbitrary price hikes - Holding data hostage - Adding ads - Arbitrary censorship, account bans - Risk of inserting a backdoor (may be forced by a government)

A centralised service is, by construction, a single point of failure, or an infrastructure choke point where control can be exerted.

In contrast, a decentralized service has multiple independent providers, giving users the choice to switch. And if the switching costs aren't too high, clients are likely to move if they are dissatisfied with the service, giving them a way out. More than that, the mere fact that users can switch keeps the original provider honest and more aligned with their interests.

The solution: Fix the incentives

Being able to switch provider presupposes that there is more than one provider. This means centralized services controlled by a single company are bad for you, your personal sovereignty and digital resilience. If you choose services that have the following properties, then you are protected against the provider turning malicious now or in the future, and the incentives are likely to keep them good.

End-to-end encryption This protects you against misuse or exposure of your data.
Open source servers (not just clients)
The most important component is open source servers. This means that even if the company disappears, another can spring up to run a compatible service. Many companies, particularly ones with end-to-end encrypted services, try to skirt around this by open sourcing only their clients, not their servers. Don't be fooled by this. Open source clients do not help you to switch providers. True freedom means anyone can run a compatible service.
Portable identity
Your identity should belong to you, not your current provider. Portable identity means you can keep your identity if you switch provider. One example of this is mobile phone numbers, which you can keep if you switch phone company. This is important because it means you can switch provider without needing to tell all your friends about your new identity.
Portable data
Most services use location-based addressing for data. This means something like a URL that points to a file, e.g. https://drive.google.com/myuser/myfile. By if I move my account and data to a different provider then those links do not work any more, especially so if the company ceases to exist. Portable data means data is not addressed by its location. This means that if you switch providers all existing access continues to work. The best way to achieve this is with content-addressed data, where data is addressed by its cryptographic hash. In this case, you can get the data from anywhere, and automatically verify that it hasn't been tampered with.
Companies without investors
If you don't have investors, then they can't sell you out. Venture capital investment in particular is famous for selling out users. The problem is that the users are not the customer, the investors are. So the company does it's best to keep the investors happy, which involves growing as fast as possible, trapping users and then exploiting them for profit to maximise returns to investors. Relatedly, check if the company has a viable business model. Are they charging customers, or are they burning investor money and giving it away for free. A good example of a company without investors is a non profit.
Multiple implementations - a standard specification
If you have a specification for the product that has multiple open source implementations then this is the best defence. In this case, the software development, as well as the providers, are decentralised.

Centralized services are digital feudalism. If you care about long-term freedom, avoid centralized, proprietary platforms. Choose systems that put you in control. Don't be a subject in a digital fiefdom, be a sovereign digital citizen.

Security audit 2024

2024-11-18T00:00:00Z

Thanks to some generous support from NLnet we have had our 2nd security audit. This was done by Radically Open Security. We are very pleased to say that 0 extreme, high or elevated risk vulnerabilities were found. There were 2 moderate, and 6 low risk issues found, and all of these are fixed now. None of the issues resulted in data exposure, exfiltration or integrity compromise - most resulted in web interface crashes. It was a pleasure working with Radically Open Security and we highly recommend them.

As part of our open approach to security and privacy we believe that audits should be published in full and made public. Read the final report here.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Reasons to prefer blake3 over sha256

2023-05-09T00:00:00+01:00

This post is a copy of tweets by Zooko Wilcox-O'Hearn.

SHA256 was designed by the NSA. BLAKE (the original) and BLAKE3 were designed by Jean-Philippe Aumasson and others (including me, but Jean-Philippe and the other contributors did a lot more of the cryptographic heavy lifting than I did).

SHA256 was based on SHA1 (which is weak). BLAKE was based on ChaCha20, which was based on Salsa20 (which are both strong).

NIST/NSA have repeatedly signaled lack of confidence in SHA256: first by hastily organising the SHA3 contest in the aftermath of Wang's break of SHA1, then by making "Don't be like SHA256" a goal for the algorithms of that contest, and then by banning SHA256 from new designs to be used by the USA government (except for in one specific cryptosystem that protects from weaknesses in the hash function https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF).

BLAKE (the original) was very well-studied during the SHA3 competition. In NIST's final report on the SHA3 process, they stated that the depth of scientific analysis applied to BLAKE exceeded even that applied to Keccak (the final SHA3 winner).

Known, feasible attacks can break 31 out of 64 rounds of SHA256 (48% of the rounds). Known, feasible attacks can break only 2 out of 7 rounds of BLAKE3 (29% of the rounds).

BLAKE3 comes “out of the box” with security features that can protect users in common use cases, such as protection against length-extension attack, a standard method of keying, "personalization tags" to guarantee domain separation, etc.

BLAKE3 is much more efficient (in time and energy) than SHA256, like 14 times as efficient in typical use cases on typical platforms.

BLAKE3 also offers performance that is competitive against SHA256 in a lot of different use cases and platforms, including some that might surprise you, such as sometimes being more efficient than SHA256 even when your CPU comes with SHA256 acceleration circuits built into it!

BLAKE3 is highly parallelizable. This provides two performance advantages, only the first of which most people think about.

The first is big data + big multicore: if the size of your data inputs scale up 100X but the number of CPU cores in your platform also scale up 100X, BLAKE3 takes only a little longer, but SHA256 takes approximately 100X times as long.
The other advantage, less widely understood, is that inside a single compute device, new tech improvements provide more and more parallel power. This is true in FPGAs and GPUs, and it is true in CPUs because of vectorization upgrades.

AVX in Intel/AMD, Neon and Scalable Vector Extensions in Arm, and RISC-V Vector computing in RISC-V. BLAKE3 can take advantage of all of it.

When you upgrade to a newer CPU/platform/device, BLAKE3 typically further extends its performance advantage over SHA256 compared to the performance advantage it already had on the previous platform!

Finally, BLAKE3 was designed and implemented by both cryptographers and software engineers. The reference implementations are super efficient and well-engineered for security, thanks to Jack O'Connor, Samuel Neves, and Jean-Philippe Aumasson: https://github.com/BLAKE3-team/BLAKE3

End of quote. You can follow our progress on upgrading to blake3 here.

A better web

2022-08-02T00:00:00+01:00

The web as it is today is, by design, ridden with hostility. The problems faced by its users fall into three main categories: ownership of identity, ownership of data, and surveillance capitalism. Websites want to own the identity of their users. This results in compromising either the convenience by having to log in to every site separately – or security and privacy, by outsourcing identity control to other third-party sites (“Would you like to log in with your Google or Facebook account?”), thus disclosing movements throughout the internet.

Websites also want to own their users' data. This means they can lock users out from their own data (or delete it) with little or no recourse. There are many examples of people losing their accounts or data in Dropbox or Google because an AI got a false positive. It also means users are forced into the provider’s interface for viewing data. Anyone who has ever been upset at a website's redesign knows this problem (e.g. see the recent outcry because of Instagram changing their interface trying to be more like Tiktok).

Big tech are hell-bent on maximising their profits at all costs - be it personal or societal. Every part of any major website is highly optimised to keep users engaged. This is the direct result of business models that compel companies to exploit their users like a resource: surveil them to serve them targeted ads, and manipulate them to spend more and more time on a website (to see more ads). There are many examples of this, quite frankly, abusive design deliberately manipulating users. Take the notification emails saying, "You've got a new message on our site, come login to see it!", when the message itself could have just been included in the email. Or the habit-forming “infinite scroll” in user feeds that tricks them into never leaving. Technology should be a useful tool, not an addictive drug that prevents consumers from doing anything else.

Apart from the above problems for users on the web, there are problems for creators as well. Creating a web app requires managing a server, arranging a domain name and TLS certificates, and perhaps running a database and handling data export and deletion requests. What if someone just wants to make some content and share it? Or maybe control access to their content so they can charge for it as well? The only viable option right now is to post to one of the big oppressive platforms like YouTube or Twitter.

The current web architecture looks like this:

The current web's architecture, where each website controls your identity and owns your data.

A better architecture for users would let people own their identity and data and selectively grant web apps access to these. This is illustrated below:

A better web architecture empowering users to own their identity and data and grant apps access to parts of it.

This architecture is exactly what we've created in Peergos. User identity is controlled by users themselves, not by their home servers, or the Peergos network. Users own their data, since it is all stored in their personal datastore, fully encrypted. Users decide who can see what.

We have an application sandbox to run custom apps. How does it work? An app in Peergos is basically just a folder of HTML5 assets. The sandbox locks down the app totally, so it can't steal private data. The idea is that even running a malicious app and granting it read-access to private data is still perfectly safe. Because an app is just a folder, access to it can be controlled – just like anything else in Peergos. Charging users for an app? Not a problem! Additionally, the app sandbox also prevents the app from communicating with its author without user consent, making tracking impossible by design. We want to isolate apps from each other, and from the main Peergos page. The architecture looks like this:

App sandbox

Each app is loaded on a unique subdomain (a hash of the Peergos path of the app code). The sandbox runs in a separate operating system process with the use of COOP and COEP headers, and CSP is used to lock down the sandbox so it can't talk to the external web. The server returns the same static assets for all subdomains. These assets simply set up a service worker, and load the app in an iframe. The service worker intercepts requests from the app for assets or API calls, and send them via post messages to the parent Peergos context, where they can be checked against any permissions the app has been granted before answering.

One of the permissions that the app can be granted is the ability to store data in a folder within Peergos. This data is owned and controlled by the user, since it is in their private drive. Other permissions include reading a file or folder, reading and modifying a file, registering to open certain kinds of files, sending messages to selected friends, and much more. We have some demo apps written here that include:

Image editor

Winamp clone

TiddlyWiki 5 - a non-linear personal web notebook

We also used the sandbox to implement a web browser for private websites in Peergos. Any Peergos folder of HTML assets can be viewed in this browser, and different sites are isolated from each other in the same way different apps are. Different websites can be linked via their Peergos path, and anyone who has access to those files can follow the links. During this process, the Peergos server doesn't see any paths or assets. All requests are handled locally just as for other Peergos files.

Such a private web is super cool because not only is third-party tracking impossible because of the sandbox, but even first-party tracking can be prevented, depending on how Peergos is run. This is how the web should be, protecting end users, not exploiting them. The inventor and futurist Buckminster Fuller once said,

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Markdown browser

2022-04-08T00:00:00+01:00

We've just released a super cool new feature - a browser for markdown documents within Peergos. This means you can nicely render markdown documents in Peergos, including inline images also in Peergos. You can link to other markdown files and browse back and forth between them. You can link to other files like PDFs, todo boards, or calendar events and have them open in the respective apps when clicked. All of this also works in secret links! It's like a secure browser within a browser.

Here's an example folder you can check out: markdown browser demo

Markdown browser

You could use this like a wiki, and grant certain people write access to individual files or sub folders. You could mirror a git repo here and use this to view the readme or documentation. The possibilities are endless.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Release the BATs (block level access control in IPFS)

2022-01-25T00:00:00Z

The main valid criticism of private applications built on IPFS is that blocks in IPFS are public. Yes, you can encrypt them, but the ciphertext is still fundamentally public. Or it was – until now. We've implemented block level access control in bitswap (the block exchange protocol used by IPFS). This means that only the people granted access to a file will be able to retrieve the encrypted blocks that constitute it. It's a ground-breaking advance: nothing else built on IPFS is this private.

In the rest of this post, we're going to talk about:

how the design works from the bitswap protocol level up to the Peergos client, and
how we turn this into an autoscaling post-quantum capability-based access-control mechanism.

To begin with, let's see how things currently work.

Unauthed bitswap retrieving a block.

When an app on IPFS wants a block of data, it asks IPFS for the data corresponding to its content identifier, or CID (basically, a hash of the data). IPFS will then search the global IPFS network for nodes that have this CID. At the same time, it will ask any nodes it's already in contact with: "Do you have this CID?". Any contacted node that has the block can respond with the data. A nice property of this is that any node that has the content can serve it up, which means that it autoscales to demand.

Authed bitswap retrieving a block.

We have extended this protocol to have an optional auth string paired with every CID. In Peergos, this auth string is an S3 V4 signature, which is time-limited, includes the CID, and is tied to the requesting node's public key (to prevent replay attacks). A replay attack would be if it were possible for someone without the block, who we had sent a valid auth token, to retrieve the block themselves directly using the token. As an anology, consider a ticketed event. If someone buys a ticket, and then a friend of theirs copies the ticket and uses that to gain entry, that is a replay attack. If, however, the tickets included the buyer's name on the ticket (they were non-transferable) and the event verified the holder's name on entry then the friend couldn't get in, even with the original ticket.

We do a similar thing to avoid this by using the source node's public key as the domain in the S3 request. This way we can broadcast a cid and auth string to the network and no one but us can use that auth string. The S3 V4 signature scheme is essentially repeated hmac-sha256 and needs a secret key to function. Such a secret key would grant the holder access to the block, so we call it a Block Access Token or BAT for short, and each is 32 bytes long. Since it only depends on hmac-sha256, which itself only depends on sha256, it is post-quantum - a large quantum computer does not break it.

The primary BAT used for this authentication is derived from the block itself. This means any instance that retrieves such a block (after being authorised) can continue to serve it up and enforce the same access control, thus maintaining the autoscaling properties in a privacy-preserving way.

There are two formats of blocks in Peergos, cbor and raw. Raw blocks are the most sensitive (they hold users' encrypted data) and are just fragments of ciphertext with no additional structure. Cbor blocks are valid dag-cbor structured IPLD objects which can reference other blocks. How could we put a BAT in these blocks? In a cbor block, it is easy to choose a canonical place to put a list of BATs. If the cbor is a map object, we put a list of BATs at the top level under the key "bats".

Structure for storing BATs in cbor blocks

For raw objects, it is a little more difficult, as we also need to support raw blocks that do not have a BAT (either legacy blocks or ones specifically made public). Our design uses a detectable prefix of 8 FIXED bytes followed by a cbor list of BATs before the actual ciphertext of the block.

Structure for storing BATs in the prefix of a raw block

We normally have two bats per block. One is inline - and specific to that block only. The other is a user wide "mirror" BAT - and referenced in the block by its hash. The mirror BAT is for when a user wants to mirror all their data on another instance, or migrate to another instance.

	Chunk 1	Chunk 2	Chunk 3
BAT stream secret	Sb (encrypted in base data)
BAT[] (unencrypted in root cbor object under "bats")	B1=randomBytes(32)	B2=hash(Sb + B1)	B3=hash(Sb + B2)

BAT derivation for subsequent chunks of a file

Each 5 MiB chunk of a file or directory has its own unique BAT, so the server still cannot link the different blocks of a file to deduce the padded size of the file. Subsequent chunk BATs within a file are derived in the same way as we do the CHAMP labels, by hashing the current chunk BAT with a stream-secret, stored encrypted in the first chunk. This maintains our ability to seek within arbitrarily large files without any IO operations (just local hashing and then a final lookup of the requested chunk). When someone's access to a file or directory is revoked, the BATs are also changed, making it impossible to retrieve the new ciphertext even with previous access.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Encrypted email storage and client

2021-11-20T00:00:00Z

We're pleased to announce the latest feature built as part of our NGI grant - an email bridge. The email bridge is a separate server that can run anywhere. It will encrypt incoming emails and store them in your Peergos space, as well as sending outgoing emails, which you create from the web interface. All it needs is the SMTP and IMAP credentials to your email, and write-access to a particular folder in your Peergos space. This is what the web client looks like:

Peergos email client.

When your email bridge receives an incoming email, it will asymmetrically encrypt the email and any attachments (so even the bridge can't read it) and store it in a folder in your Peergos space. When you next login, you decrypt the email and any attachments, and store them in a private folder the bridge doesn't have access to. In the other direction, you can create a new email which is stored in a file in your Peergos space. The bridge picks this up, sends it as a real email, and deletes the file from the Peergos outbox folder (you keep a private copy that the bridge can't read). It's designed in a way that there is no state stored in the bridge; therefore even if it is temporarily compromised, no emails are exposed other than those sent or received during the time of the hacking.

You can run the bridge anywhere, it doesn't need a domain name or any TLS certs, just your smtp and imap credentials, and write-access to a folder in your Peergos space. To achieve the latter easily, create a new Peergos user just for the email bridge. Then you can friend and share with this user naturally using the existing Peergos interface.

Compose an email in Peergos.

Want to try it out already? You'll first need to run your own email bridge and create a Peergos account for the bridge. Then to enable the email client in Peergos, login or create an account at https://peergos.net/?email=true - note the "?email=true" in the URL. Then login and open the email client in Peergos, and put in the username of the email-bridge. Then login as the email bridge user and accept and reciprocate the follow request from your user. Add your username to the email-bridge accounts file to allow sending/receiving emails.

This work was built as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Decentralized encrypted chat

2021-11-12T00:00:00Z

We're pleased to announce the latest feature built as part of our NGI grant: decentralized encrypted chat. Why build yet another chat protocol, you ask? Our implementation of chat is an application inside Peergos, i.e. it benefits from all the privacy guarantees and access control without having to re-implement all of it.

First, let’s see how it looks.

Decentralized encrypted chat.

The user interface is fairly familiar. However, one difference to most messengers is that it is built to respect you and your attention: no notifications and no nagging pop ups to "install our native app where we can track you more". You can only chat with your friends on Peergos. No unwanted messages - you have to accept someone as a friend before they request a chat with you. All you need to start a chat with a friend is their username - unlike some messengers that demand your phone number, and require you to share it with those you chat with.

You can do all the usual things: textual messages, images, videos, emoji. The app allows one-to-one chats and group chats. Group chats can have any number of members and any number of admins; admins can grant and revoke admin status to others. Your Peergos server doesn't even know you're sending chat messages, because these are just regular files in your Peergos space.

Group chat.

Under the hood, each chat stores its messages as an append-only file in Peergos. Messages are not pushed to other recipients - to send a message, you simply append it to your own copy of the chat log. Other members will then pull the message and copy it into their log the next time they open the app – messages propagate peer-to-peer, from member to member. The messages themselves form a merkle dag with each message containing a merkle link to previous messages. With this structure, we are able to maintain causal order. That means you only see a reply to a message after seeing the message it is replying to. In group chats, when a member leaves, or is removed from a chat, then their access to the chat is revoked, preventing them from seeing any future messages.

Want to try it out already? To enable the chat app, simply login or create an account at https://peergos.net/?chat=true - note the "?chat=true" in the URL. We will enable chat by default once the UX is more polished.

This work was built as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Peergos launches decentralized & encrypted social media

2021-04-12T00:00:00+01:00

We've written before about the problems with existing social media and how we think they should be solved. After a few months hard at work, we're launching our decentralized and end-to-end encrypted social network!

Private social media.

As you would expect from any social media app, you can create posts with text, images, video or audio and choose how the post is shared - with your friends only, or all your followers. Commenting on a post will re-share and increase the audience for the original post in line with the author's intent (friends or followers) without exposing anyone's social network. You can't see all the friends of someone, even if you are friends with them. See the gif below for how to access your social feed.

To access the Peergos social network, log in, click on apps, and then the social feed icon.

So why an encrypted and decentralized alternative? There are many problems for both society and individuals caused by current social media - including huge data breaches to increased polarisation and threats to democracy. We believe social media should be designed with the interests of the end-user in mind and that a fundamental requirement is agency for people over what they see and who they interact with. In Peergos, you only see content shared with you by your friends or people you follow. End-to-end encryption of your social feed means that mass data gathering and surveillance is not possible. Without the ability to gather data, machine learning algorithms cannot be trained and you cannot be targeted with content or ads (sorry not sorry, Cambridge Analytica).

What about decentralization? If you've used email then you've used something similar called a federated system (federation is a weaker form of decentralization). Anyone can run an email server, and those servers can all talk to each other. Changing your email address is painful though because your identity is tied to your hosting provider. If you want to move from Gmail to another provider you need to tell all your contacts about your new email address.

In a decentralized system such as Peergos, identity is self-sovereign and under your ownership. If you want to move to a new server, you can do this whilst keeping all your friends, followers and data. All links continue to work unmodified. This is because data is retrieved using content-addressed and public key-addressed requests thanks to the magic of building on IPFS. There is no location-based addressing anywhere in our protocol (including DNS). You're even able to change servers if your original host server becomes malicious. No other social network can do this currently!

Finally, we've wrapped all this in a humane user interface that's explicitly designed not to optimize for ~~user engagement~~ addiction. Social media should enhance your life, not become your life.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This work was built as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Private and customizable profiles

2021-03-22T00:00:00Z

Our latest feature is another step towards making it easier to connect with your real life friends, family and colleagues on Peergos - social profiles! It goes without saying that we've put quite a bit of thought into how we can make sure you're able to keep certain pieces of personal information private and secure, while making other pieces public. Our solution: profiles that display only the information you choose to share with your friends on Peergos.

You can now create a profile and set an image, status, bio and all the usual fields like email, phone, first name and last name. What you choose to fill in is up to you! What's more, you control who can see each of these fields by granting read access to each field to individual users or groups such as your friends or followers on Peergos. As you'd expect from Team Peergos, everything is end-to-end encrypted and the server can't see anything.

To get started, signup or log in to your existing account, click on the settings button in the top right hand corner and select "Profile". This will bring up the profile screen. Simply fill in some details, click "Save Profile", and then you'll be able to select who gets to see which parts of your profile. It's like having a fully customizable business card!

Setup your private profile and control who can see which parts.

How does this work, you ask? Under the hood, each field on your profile ends up as a file in Peergos, which means we can leverage our built-in access control easily. We just agree a convention on the path, e.g. /username/.profile/firstname. Then, anyone trying to view your profile can only see the parts you've shared with them.

A friend viewing Robin Hood's profile. They've only been granted access to a few fields.

This work was built as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Simple decentralized web hosting on Peergos

2021-03-01T00:00:00Z

You already know that Peergos lets you store and share files securely and privately. Now, you can also host your own website on it!

We always thought getting a website up and running should be one of the easiest things to do on the web. There are plenty of options available for website hosting, but with Peergos there's no need to buy a domain name, arrange TLS certificates, or run a server to host the content. You also don't need any cryptocurrency to post or update your website, so you can get free instantaneous updates and peer-to-peer authenticated delivery. You can sign up to our server today and get started right away in just two easy steps:

Upload your website files to a directory in Peergos.
Go to your profile, set that directory as your website and click publish.

Your personal website will now be available at https://<your-user-name>.peergos.me. It doesn't get any simpler than that. Let's see this in action!

Host your decentralized website directly from Peergos.

Any changes made to your website files are automatically and instantly reflected in your website. When we say instantaneous, we mean it. Check it out below!

Instantaneous and free updates to your decentralized website.

When you publish a website from Peergos, you can view it through any Peergos gateway. We're running one at peergos.me, so your website will be available at https://<your-user-name>.peergos.me, and viewable in any browser today. Bear in mind that viewing through a public gateway like that still relies on DNS and the TLS certificate authorities, which are both single points of failure that are vulnerable to attack. However, we can actually get around both of these by viewing someone's site through a local Peergos gateway. To visit someone's site in this way, you just run a local Peergos instance and browse to http://<username>.peergos.localhost:9000. The gateway looks up the public key of the username provided in the localhost subdomain via the Peergos PKI, then retrieves the website and serves it. All this is done without relying on DNS or TLS certificates anywhere. We are thus able to use localhost subdomains to achieve isolation and security between different sites served from one local gateway.

Websites hosted on Peergos benefit from our resilient and reliable decentralized architecture. Most of the heavy lifting is done by IPFS through content addressing and public key based routing. With our architecture, we add fast mutable pointers and human-readable names. Therefore, you can trust that the content of your website will be readily available without having to rely on a single-point-of-failure-server anywhere.

In the future, we will enable viewing such websites directly inside the Peergos web interface. At that point, Peergos will really start to look like a new web.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Stay tuned for introductions to a few other new features and apps we're building as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Encrypted shareable calendar

2021-02-07T00:00:00Z

We are very pleased to announce the latest Peergos application: a private calendar. The calendar is fully end-to-end encrypted, and allows you to share individual events securely – both with friends on Peergos and externally via secret link. Events are standard iCal files, and can be imported or exported to other calendar apps. You can even share entire calendars! You can create multiple calendars, and events can be one-off or repeating.

Interestingly, as the calendar is written on top of Peergos, the app itself doesn't include any encryption or sharing code, because the underlying Peergos layer handles that.

Create and share private events to manage your schedule.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Stay tuned for introductions to a few other new features and apps we're building as part of our grant from the Next Generation Internet program (NGI POINTER).

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Fast Encrypted File Search

2020-12-22T00:00:00Z

A much requested feature in Peergos has been the ability to search your whole Peergos space for files. This is more difficult than it sounds in an end-to-end encrypted setting.

A normal web app like, say, Facebook, would implement search by just sending the query to the server, which would then do the search for you, and return back the results. This is only possible because in websites like Facebook the server can read all your data. We don't have that luxury and so we had to take a different approach to search. First, let's see it in action.

Search for files by name, type, size or modification time.

To implement search in Peergos we have to do it all client side, without exposing anything to the server (remember, our servers are trustless). Luckily, our systems are designed with this in mind, so you are able to search all the properties of files like name etc. without downloading and decrypting the entire file, just a small amount of encrypted metadata. In the future we might consider constructing an encrypted index of your files to speed things up further but it's plenty fast enough now for many use cases. You can search by name, modification time, file type or file size. If you want to limit your search to a particular directory you can right click on the directory and select search.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

Private Planning Boards in Peergos

2020-12-09T00:00:00Z

Working on a new project and need to keep track of multiple tasks or workstreams? Peergos has got you covered! We're excited to announce the first in a series of new apps in Peergos - kanban boards! Our kanban boards are multiple, customisable to-do lists, which help your workflow planning.

Stay on top of everything you need to get done with kanban boards in Peergos.

We love kanban boards! Most of us here at Peergos have used them at various companies or even personally to stay organised. As much as we love them, we've always been hesitant to use existing kanban board solutions due to privacy and security concerns. These boards often contain personal or confidential information - if you're part of a dev team working on an awesome new product feature that's going to dominate the market, you absolutely want to ensure that any details are kept away from prying eyes. So we built our own!

You can now create a kanban board anywhere in your Peergos space - simply click on our application menu in the top left-hand corner (spoiler alert: you might see some applications there we haven't told anyone about yet) and then click on the nifty looking icon. Our boards have all the features you'd expect like dragging and dropping within and between lists to re-order, easily marking entries as done, or deleting them.

Applications menu button

What makes our kanban boards special? All of the data for a given board is stored in a single file and end-to-end encrypted so no-one but you can see what's on your board. Unless, of course, you want other people to see your board! Just like any other file in Peergos, you can grant your friends read or write access to your boards, and even share them via secret links, which anyone can use. No need to worry about complicated access control, everything is securely handled by Peergos so you can focus on staying organized and getting things done.

So whether it's tracking your shopping list, planning a big project or managing your time, try out kanban boards in Peergos. We're using it as an internal project management tool, and one of our core team members is currently using a Peergos kanban board to manage their house sale and move!

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the NGI-POINTER Project funded under grant agreement No 871528

How to solve the social dilemma and fix social media

2020-09-20T00:00:00+01:00

Still from the Netflix documentary, The Social Dilemma

Netflix recently aired a new documentary, "The Social Dilemma", which explores in detail the harmful effects that social networks such as Facebook and Instagram have on individuals and society at large. One of the interviewees in the documentary, Jeff Seibert, has written a more detailed piece on the underlying causes, methods and impacts of current social networks on society and democracy. He argues that advertising-driven business models combined with user-generated content and machine learning lead to increased polarization and anxiety, widespread misinformation, and mass-scale manipulation of society. Some proposals to fight this include regulation, like the General Data Protection Regulation (GDPR), which place strong controls on collecting data on users, even potentially banning personalized advertising.

We agree with Seibert, and we also have a solution. Regulation has the danger of increasing the power of the dominant incumbents, if it's not done correctly. They treat it as a burden and moat preventing competition, and competition is what is needed most. What new competitors need is a different business model. A business based on selling ads is not aligned with the interests of its user base. What if, instead of advertisers being the customer, the actual end-users were the customer? If users paid a small amount on a subscription basis, then the business would be incentivized to keep customers happy. This model may not maximize revenue for the company, but so long as the company is sustainable and able to grow, then that shouldn't matter. The apparent obsession with maximising revenue and growth at all costs is not healthy, and models in which users pay directly for services are better in the long term - for individuals and for society.

Whatsapp was a great example of a succesful subscription-based business. They started off charging a subscription of $1 per year. At the time of their acquisition, in 2014, Whatsapp had 450 million monthly active users, and annualized revenue of around $32M [source], and were adding a million new users every day [source]. For a company that had only 55 employees and operating cost around $10M, that sounds sustainable. Whatsapp also weren't really pushing for monetization, but rather growth. For example, they were relaxed about enforcing the $1 fee after the first year, and didn't apply it at all in certain countries. For comparison, at the time Facebook was making $7 in revenue per user.

Even a good business model can change depending on who owns the company. If investors or shareholders demand that profit is maximized, then that's what you have to do. To prevent this you either need to have benevolent investors, who aren't focused on maximising revenue at all costs, or don't have any investors. This could mean being entirely self-owned, or being a non-profit organisation. This alone probably isn't enough though - what's needed are built-in defences keeping any potential future owners honest and aligned with the users.

One of these defences to keep the company's interests aligned with the users is to reduce the barrier to leaving. If the social network is decentralized then this is structurally enforced. In that case, if the company starts to misbehave in some way, users can easily move to another company (or self host) and keep all their data and friends. This is not possible with centralized social networks without open protocols. An open protocol actually takes this even further, as the user interface itself can be replaced. If the company were to start adding malicious features to the interface, people can simply switch to a different one. Combining this with being open source means it is also easy to modify the existing user interface. Social media incentives have never been this aligned with the users before.

There is still one major ace card to be played to protect users: end-to-end encryption. If the service cannot read your data, then it is impossible to target ads, even if they wanted to. This means that any social feed cannot be an arbitrary black box machine learning algorithm - it has to be assembled client side, thus putting end users in full control of their data and returning their autonomy.

The final component is ethical humane design. That means designing for the good of the human user. No manipulative notifications or dark UI patterns designed to increase engagement and steal more of the user's life. Social media should be a tool that is used to enhance people's lives, not something that manipulates people into spending more time on it.

"If something is a tool, it genuinely is just sitting there waiting, patiently. If something is not a tool, it's demanding things from you. It's seducing you. It's manipulating you. It wants things from you. And we've moved away from having a tools based technology environment, to an addiction and manipulation based technology environment. That's what's changed. Social media isn't a tool that's just waiting to be used. It has its own goals, and its own means of pursuing them by using your psychology against you."

-Tristan Harris in The Social Dilemma

Putting all of the above together, what is needed is an open, decentralized, end-to-end encrypted and ethical social network whose business model is subscription based.

That's exactly what we're building.

Peergos wins EU Next Generation Internet grant

2020-08-31T00:00:00+01:00

Peergos, supported by EU - Next Generation Internet

We are proud to announce that Peergos has been awarded a €200,000 grant by the Next Generation Internet Program for Open Internet Renovation (NGI-POINTER). We are incredibly excited to have been identified as NGI Architects and selected for the program, as it is both ambitious in scope and aligned with our values. We will be using this opportunity to develop new and exciting features for Peergos that will see it evolve into a privacy-focused, decentralized social network.

NGI-POINTER aims to find ambitious "NGI architects" to change the underlying fabric of the internet and the web. It does so by supporting promising bottom-up projects that are able to build, on top of state-of-the-art research, scalable protocols and tools to assist in the practical transition or migration to new or updated technologies, whilst keeping European Values at the core.

NGI-POINTER is funded by the European Union's Horizon 2020 initiative which is designed to stimulate innovation and economic growth. We strongly believe in the fundamental values that the EU stands for: respect for human dignity and human rights, freedom, democracy, equality and the rule of law. In fact, the EU Charter of Fundamental Rights explicitly mentions the protection of personal data and the right to privacy.

We've previously received support from Protocol Labs and through the Oxford Foundry accelerator program which has enabled us to work on particular aspects of Peergos and grow as a company. Up until now we have been reliant on time and work volunteered by our core team, so a grant of this size represents a step change for us. At least two of our core team members will now be able to work full-time on Peergos.

The NGI-POINTER program will run for a year, so we have a lot of work to do in a short space of time. Alongside this project, we will continue towards our goal of becoming a bootstrapped business by offering subscription plans for private and secure storage, hosted by us! We think this is the best way to keep our incentives aligned with those of the Peergos community.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

NGI POINTER (NGI Program for Open Internet Renovation) has received funding from the European Commission, as part of the Horizon 2020 Research and Innovation Programme, under Grant Agreement No. 871528.

Direct S3 access

2020-08-16T00:00:00+01:00

Peergos uses IPFS to store its data and IPFS supports several kinds of blockstores, from various kinds of local disk based storage to an S3 based store. The S3 store is useful because it automatically provides redundancy and availability, and can also hold much more data than any disk. There are also many providers of S3 compatible storage now. For a while now, we've supported using the S3 based blockstore in Peergos. However this wasn't visible to end users, it was only a server side thing. This means that when uploading or downloading data it all had to go through the Peergos server.

The flow of data in previous S3 usage, which proxied through the Peergos server

We have now implemented direct S3 access for reads and writes from the browser/client. Clients can read and write directly to an S3 bucket after authorization from the Peergos server. This new feature makes the Peergos server much more scalable and reliable. The typical bandwidth required of the Peergos server is reduced by ~100x.

There are two modes of read operation; public and authorised. In public mode, all encrypted blocks can be read directly from S3 without any permission. This is the fastest, but may not suit your pricing model for S3. In authorised mode every read request has to first get permission from the peergos server, which signs a url that is temporarily authorised to read that object from S3. The client then directly downloads the block from S3. This is illustrated below.

Direct S3 reads

This is all very well, but what about writes? What if there are many users on the same server? This is where it starts to get beautiful... All users on the same Peergos server share the same S3 bucket, and yet there is no possibility for conflict! This is because the blocks in S3 are content addressed! When a client wants to upload a block they first pre-authorise the block hash with the peergos server which returns a signed url the client can use to upload directly to S3. Upon upload, S3 automatically checks the sha256 hash and size of the block with what was signed. The data flow is shown below.

Direct S3 writes

It should be clear how this takes most of the load off of the Peergos server, thus allowing a single server to handle many more users.

The kind of functionality required for this isn't actually exposed by the official S3 SDK. So to get this working we had to implement our own version of the S3 client. It's remarkably simple and only took us a single class, without any dependencies except an hmac-sha256 implementation. The added benefit of this is that we've been able to remove the amazon S3 sdk entirely from our codebase, which was 60mb of dependencies! Compare this with the rest of Peergos including all dependencies, which add up to only 16mb.

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Peergos release v0.3.0

2020-08-10T00:00:00+01:00

Privacy is alive and well at Peergos as we continue on our mission to build the private web where you are in control of your data and identity.

We are pleased to announce the release of v0.3.0, and it's a big one! You can try it out on peergos.net now. This release patches a number of bugs in both the server and the client, and also brings a host of cool new features. There's too much to talk about in a single blog post, but we'll mention everything briefly before diving deep in later posts.

Some of the highlights include:

Performance improvements

S3 datastore - read and write directly to S3 from the browser without proxying through a Peergos server
GC is now fully concurrent and doesn't have any "stop the world" pauses
Smoother HD video streaming through a buffered async reader

Client

Improved sharing UX
Saving a document in the text editor is now 7x faster
Easily delete your account and all your data

Server

Privacy-respecting payments - self-host a Peergos server and charge for storage
Easily install and run IPFS via a top-level command
Expanded quota APIs
Postgres is now supported as well as SQLite

Protocol upgrades

Upgrade to IPFS v0.6.0 - see the release notes here.
Support base36 and base64 in multibase
Limit identity multihashes to 36 bytes

We are particularly proud of the direct S3 datastore as it allows a Peergos server to use S3 compatible storage for the blockstore. Clients can read and write directly to an S3 bucket after authorization from the Peergos server. This new feature makes the Peergos server much more scalable and reliable, and gets around the need for complicated access policies when using S3. We will be exploring this feature in more detail soon!

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Keybase has left the building

2020-05-11T00:00:00+01:00

It's a story that most of us have heard before. You found this cool new service, and you sign up and invest time and energy learning how to use it. Things are great! Then at some point it gets bought or otherwise acquired. There will be promises that the service will continue to run as per usual, probably even improve, but sooner or later the announcement comes that it's being shut down. There goes the tool you've relied on for years. If the tool happens to be a social one, where you've had to convince your friends or colleagues to use it, then you are doubly-burned.

You may have seen the recent news that Keybase has been acquired by Zoom. If you haven't heard of them before, Keybase links your social accounts to a Keybase identity in a cryptographically provable way so that people can verify you are who you say you are. On top of that, they also offer end-to-end encrypted chat and secure file storage.

This is looking like an acqui-hire and is probably a good thing for Zoom and Keybase employees. However, if it is an acqui-hire then it's quite likely the Keybase product will be shut down eventually. I hope this isn't the case as Keybase is a great product. However, this is unfortunately an all-too-common exit mode for centralised, closed source systems and while it may be ultimately very profitable for the company being acquired, it very often leaves the users in the lurch. If you (the user) are relying on a particular server to function (or DNS itself) then the product you are using can be taken away from you permanently (or temporarily for that matter) by buying or influencing the owners of that server, or simply blocking them on a network level.

This is why I'm very careful about what new services or software I sign up to. Life is too short! If the software satisfies the following then it has some built-in defences -

1) Open-source

If the software is open-source then, if you really wanted to, you could host your own version of it, or pay someone to set it up for you. Note that this means both the clients and the server need to be open-source. If only the clients are open-source, then you are still locked in and dependent.

2) Allows data export

Being able to self-host is of limited benefit if you can't also export your existing data from the platform. This ties into the broader issue of data ownership.

3) Decentralized

If a service is actually decentralized (not just federated) then you don't depend on a central server at all. In this case you don't actually need to "export" your data, you just migrate server. Ideally, migrating to a different server doesn't mean you lose any social data, or have to tell your friends etc - this is true if your identity is independent of your hosting server.

4) Viable business model with paying users

Finally, if a service has a viable business model where users are paying, then the interests of the business and the users are much more aligned. Contrast that with advertising-based businesses where third-party advertisers and user data are key to revenue.

It may still be premature to say we're losing Keybase, and I hope Zoom listens to the Keybase user community and keeps on offering and developing this product. In the meantime, if any Keybase users are now looking for a replacement storage service - one that has all these defences built-in - have a look around our site and make yourself at home!

The perfect social network

2020-01-11T00:00:00Z

What do most people want in a social network? We all have different ideas, but is it possible to have a set of features that makes everyone happy? We think so!

This is the Peergos list of user-focused requirements for the Perfect Social Network:

Sharing media of any size with any number of people, including "the public".
Universal login - logging in on any device (even when all devices have been lost).
Unique usernames (human-memorable).
Location-independent identity - users should be able to change hosting provider without losing data or friends.
Offline functionality - the ability for many functions to continue to work offline.
Private data - the users decide who sees their posts, and the platform, as well as any server operators, can’t access them.
Private metadata (including the social graph - who connects with whom and when).
Post-quantum (safe if a large quantum computer is built).
Free from targetted ads, or an engagement/outrage-optimised algorithmic feed.
Fine grained access control - the user can restrict visibility of individual posts.
The ability to delete or modify data.
Self-hostable - for those who want more control, whilst still interacting with everyone else.

So why do we think these points are important?

They fall into three broad categories: convenience, privacy and control.

Convenience

This one’s critical - if something isn't convenient, then most people won't use it. But what do we mean by convenience?

For instance, we are used to having unique usernames on services like email, Twitter, Instagram etc. This enables everyone to unambiguously find friends via a human-memorable name; it also gives an entry point to log in from anywhere. At the moment, many architectures rely on generating keys on each device, and require an existing device to authorise a new one (e.g. Signal). However, this means you cannot log in if you lose all your devices.

How many times have you switched email addresses and had to tell all your contacts about it? A location-independent identity means that we are free to choose where our data is stored, and move providers without any loss of data and whilst maintaining our full social graph.

Can we still do anything if the internet is down? Is it possible to search old messages or write new posts without internet access? Most folks would love a social network with offline functionality.

Finally, sharing large files. Unfortunately, this requirement rules out a lot of currently available architectures: in some popular social networks, sharing a 4 GB file with friends entails storing 4 GB on all their devices – and in append-only structures (i.e. ones you can only add to, never remove from) these files can't even be deleted!

Privacy

Privacy is a fundamental human right, and the best way to protect it online is with end-to-end encryption of all data. Beyond that, to maintain freedom of association, we need to also safeguard metadata, in particular the social graph – i.e. not only protect what you send, but also what size, to whom and when. The need for full protection rules out protocols that expose lots of data and metadata to both the server administrators and the rest of the network (e.g. ActivityPub).

Privacy isn't very good if it is temporary. Given the possibility of a large quantum computer being built, it is important for any privacy-focused protocol to plan for it.

Control

Many users would like more control over their data online, especially in social networks – and control comes in different flavours.

Control over your own social feed means that you cannot be manipulated by the platform or its advertisers (as seen in recent elections!). Ideally this is not just a promise by the network operator, but a property enforced by design.

Fine-grained access control allows users to do what they do naturally in life – control the flow of their information, whether it's private communication with a friend, or keeping work, family and friends separate.

Control over modifying or deleting data allows us to be, well, human. People frequently make mistakes and might want to modify something, or simply clear up some space.

And for those who want Even More Control, the system must be self-hostable. This also keeps the platform honest - a non-self-hostable (centralized) platform can do whatever it wants, and users have no choice but to accept any changes or leave the network entirely. To allow for self-hosting, the platform should be fully open source, including any server code.

At Peergos, we already tick the above boxes, except offline functionality and post-quantum – both of which are partial ticks and in progress. Currently we look more like a global social file system, but we will be adding a more traditional social feed in the future. Watch this space for more progress reports!

Do you agree with our list? What is YOUR perfect social network like? Tweet us at @peergos with your ideas!

Atomic access control

2019-11-15T00:00:00Z

At Peergos we care deeply about your privacy, and the core of privacy is access control. Controlling who can see what. We've made some big improvements in this area for our new v0.1.4 release, so let's learn some more about them.

We have totally rewritten our access revocation implementation. Previously there were some issues with nested write access which could cause data loss. Now in the new version, revoking write access is a single pass over the files and directories you are revoking access to, rather than 3. We've also made it atomic. This means your machine can crash at any point and your file system is in a consistent state with all data present.

Similar improvements have been made to revoking read access and we are working on fuzzing the access control mechanism to further assure correctness and safety. While we had the hood popped open, we also removed unnecessary reloads of the current directory which has made the web interface much snappier.

New public link UI for https://peergos.net/public/peergos/releases

We also have a secret to share with you - we have a mechanism for making files public, though it is not added to the web interface yet. Each user can choose to publish a capability to a file or folder that is readable to anyone. The mechanism for this is each user publishing a merkle CHAMP root, which is a lookup from path to capability. This is currently only used by the "peergos" user for releases of Peergos itself: https://peergos.net/public/peergos/releases.

Old public link UI for https://peergos.net/public/peergos/releases

Prior to this release, public files were decrypted server side after retrieving the capability from this CHAMP and delivered directly to the requestor. Clearly if we allowed anyone to use the feature then it would be a trivial cross-site-scripting (XSS) vector. So, in preparation for allowing all users to publicly share files, we now make the server retrieve the capability, and then do a http redirect to a "secret link" to that file. This means we get the full Peergos interface for navigating, viewing and downloading public files, and removes the potential for XSS attacks. The file or directory then becomes accessible under the human readable url

https://peergos.net/public/$path-to-file

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Peergos release v0.1.3

2019-09-15T00:00:00+01:00

We've been hard at work, so hard in fact that we're only now writing another blog post. We've sped everything up, enabled native builds, added garbage collection, added S3 storage support and fixed several bugs.

Everything in this post is contained in our latest release, v0.1.3, which you can try out on our server

The most obvious change is that we've sped most things up by ~2.5X, notably uploads and downloads. Our download speeds are now comparable to Dropbox, despite the extra overhead of decryption!

2.5X faster downloads

The next big feature is transaction-aware garbage collection. This is critical to ensure our disks don't unnecessarily fill up.

If you change 1 byte of a file bigger than 5 MiB, then we reencrypt that 5 MiB section of file. The new cipher text for this section has nothing in common with the old cipher text (otherwise it wouldn't be very good encryption!!). This means that now 5 MiB of blocks are unused and wasting space. Eventually, with enough modifications you'd fill up the disk with all this garbage.

Too much garbage

The operation that cleans up these unreferenced blocks of data is called garbage collection. The difficult part is making sure we don't garbage collect data that someone is in the middle of writing (before they commit it). At the moment, this is achieved with a process wide lock. Once IPFS implements native transactions we can remove this global lock and get much better throughput.

The next addition was statically compiled native binaries. Until now, to run Peergos yourself you had to independently install Java, which is ~100 MiB. This is an extra barrier that makes it harder to use, and which some people aren't willing to do. The native builds:

are smaller in total size (32 MiB compared to a 13 MiB jar plus a 100 MiB JVM);
use much less RAM than a full JVM;
start much faster than a JVM (4 ms compared to 660 ms).

The last feature in particular enables us to have an interactive command line interface which doesn't require running a daemon. We'll be writing more about this soon! The only negative of native image builds is we don't yet have reproducible builds for it.

The final feature in this release is support for using an S3 compatible service for data storage instead of the local hard disk.

As well as all these new features we've fixed a host of bugs in both the server and the client. So head on over to peergos.net and check it out!

Applications on Peergos

2019-08-20T00:00:00+01:00

They're here - the first apps for Peergos!

The first application we've made available is a read-only viewer for PDF files. This is a super-simple app which adds very useful functionality to Peergos. Now you can securely and privately read PDF files within Peergos.

PDF Viewer

The second app we've enabled is an editor for text or code. We support plain text, markdown, and major programming languages like Java, Go, Rust, Javascript, HTML, etc. This is huge! You can use the text editor as a secure password manager, a to do list and more!

Text/Markdown/Code editor

These great new features are made possible by a technique we've recently discovered. The key component is a sandboxed iframe. Browsers now let you lock down code in an iframe so that it can't communicate to the outside world (i.e. can't make AJAX requests) and is totally isolated from the parent web page. The isolation provided by the sandboxed iframe is absolutely critical to us because when you are logged in, your keys are stored in memory and must be protected from any potentially malicious code. We can run untrusted code in a sandboxed iframe which only lets you render HTML, CSS, run Javascript, and send and receive specific messages to and from the parent. This messaging API keeps privileged code and keys separate from the application running inside the iframe.

For the PDF viewer, we simply imported pdf.js from Mozilla and implemented a one-way message from the external context which sends the content of the PDF to render. For the text editor, we used a great library called Codemirror. This app required a slightly more complicated protocol than the one-way message system of the PDF viewer. We just needed a message to send the modified content back to the external context, and the privileged code could then save the modified file contents.

One of our goals has been to enable third party applications inside Peergos. These would be apps which you can choose to install and grant permissions to using the strong authentication, encryption and access control in Peergos, but which run in a strict sandbox. Eventually we want to allow users to edit HTML and Javascript files directly in a folder in Peergos and declare it as an application. This would give users a live editing environment, easy publishing, and auditable proofs of the authorship of apps. You could even host your website directly in Peergos and edit it in place!

Before we open up the sandbox to truly untrusted apps, there is one prerequisite. Currently, browsers don't put sandboxed iframes into a different operating system process, which is necessary to be fully protected from CPU vulnerabilities such as Spectre or Meltdown. Both Firefox and Chrome are in the process of moving iframes to separate processes and once that lands, we can enable 100% safe sandboxes for Peergos applications!

In the meantime we can use it to curate semi-trusted apps like the PDF viewer and text editor. We'd love to hear what you use the text editor for!

Happy Peergossing!

-The Peergos team

Fast seeking and encrypted history

2019-08-01T00:00:00+01:00

Another week, another set of cool new Peergos features. We've been hard at work and wanted to tell you about our latest new features: super fast seeking within a file, encrypted history (fix the back button), and storage usage and quota display.

Imagine you were watching a long movie in Peergos using our built in streaming video player, and wanted to skip ahead to where you left off last time, around two hours in. Previously this involved downloading the encrypted metadata for every 5MiB chunk of the file (a few network requests), decrypting the location of the next chunk, and repeating this until you reach the desired offset. The links between the chunks are encrypted so that the outside world (or the server) can't deduce the size of your files. This was SLOOOOOW. To seek a gigabyte or so in took about 5 minutes, or more depending on your internet connection latency! No one wants to wait around that long. so we came up with a new scheme for deterministic, but still private subsequent chunk locations. Before this change each chunk location was 32 random bytes. In the new scheme we calculate the location of a subsequent chunk as the following, where the secret is 32 random bytes that are stored in the encrypted metadata of the first chunk of the file:

next location = sha256 hash(current location + secret)
How we now calculate the locations of later parts of a file

This means that to seek ahead we don't need to do any IO at all. We just do a bunch of hashing locally. This is ridiculously fast and doesn't leak to the world the connections between your chunks. We can now seek many gigabytes into a file in about 5s, which is mostly the time to retrive the eventual chunk of the file.

http://localhost:8000/#{%22nonce%22:%22hl6U6X/ytjRGT+pi5wmJFq...,%22ciphertext%22:%22oK9JAGotzDOELvIon...}
A URL with the encrypted path in the fragment.

The second feature this week is encrypted history. Until now, if you press the browser back button you get logged out of Peergos. Super annoying! Now, every time you change directory we store the path, padded and encrypted, in the url fragment. If we didn't encrypt it then there'd be a log of every directory you visited in your browser history. The other requirement is that we catch changes to the url (e.g. caused by pressing the back button) and try to decrypt and interpet the resulting path. This makes navigation much more intuitive.

We also add to the history if you open a file in Peergos, and if you log in through one of these links then we will restore you to the correct directory, and open any file you had open. This allows you to store "deep bookmarks" to things in Peergos which don't reveal anything to someone who get's access you your bookmarks!

Space usage display

The third feature is a display of your current space usage and allowance. This lets you see at a glance how close to your limit you are, and you can request more from the admin for your storage node. That could be a friend who's running a Peergos server for you and gives you more storage for free. Or later down the line we will add the ability for a hosting provider to charge money for storage. After you've requested more storage an admin can approve it next time they log in.

Request more space

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Happy Peergossing!

-The Peergos team

IPFS Camp, new features

2019-07-16T00:00:00+01:00

At Peergos we care deeply about your privacy and security online. We are super-excited to be building the future of the web where individuals have total control over their data, and who can see it. This is why we prioritised getting a full security audit and why we continue to build a privacy-first platform where you grant applications and people access only to the data you want them to have.

Recently we attended the inaugural IPFS camp organised by Protocol labs from 27th-30th June. Set in magnificent surroundings in the Barcelonian hills, the situation was primed for productivity with 160 pioneers of the decentralised web gathered to meet, discuss, learn and solve. The schedule was packed, with core courses, electives, lightning talks, deep dives, unconf sessions and a sci-fi fair. It was a great experience and hugely useful for Peergos and our mission.

Best deep dive trophy

Our team member Jonathan and his group won the best deep dive, for a product analysis of Peergos. This deep dive was a guided user testing of Peergos which resulted in a ton of feedback and suggestions. One of the suggestions was to implement friend verification in person or over the phone via a qr code or safety number. In fact, one member of the group said they would pay right now for Peergos if it had this feature! So now, a few weeks later, we present friend verification! It works directly from the browser using the webcam, including on mobile. Just scan your friends qr code in person for an added layer of confidence!

QR code based verification of friends

We already have many defenses against a man-in-the-middle attack including mirrored append-only certificate transparency for all user identities, but this adds another layer for the hyper paranoid users.

Another suggestion from our deep dive was that uploading a folder should work. We've attempted this in the past but hit problems with the browser APIs. However, now we have solved the problems and you can drag and drop a folder into Peergos and it will recusively upload all its contents!

We also had a great deep dive session with Berty on a secure decentralised group chat protocol. We were investigating if Messaging Layer Security can be adapted to work in a more decentralised setting. Berty also presented their implementation of a libp2p transport over bluetooth low energy. Very cool!

Want to be part of the future? Create an account on https://peergos.net or self-host your own private personal datastore.

Until next time, happy Peergossing!

-The Peergos team

Alpha Release

2019-06-20T00:00:00+01:00

The time you've all been waiting for has arrived... The Peergos alpha is now officially open! You can now have your own private shareable space online.

We have a strictly limited number of accounts on our alpha available for free with an initial 200MB of storage, so get in fast. All we ask in return is that you use it and tell us what we can improve. You can do this in Peergos itself using the feedback button, on Reddit, or via email or Twitter. If you run out of space in Peergos then just message us and we'll increase your storage quota, subject to availability.

Some things to bear in mind:

We haven't had an external security audit (coming soon), so we advise you not to store anything sensitive in Peergos yet.
For now, we recommend Chrome for files larger than 50MB. We'd love to be able to recommend Firefox, but they haven't implemented a [critical feature](https://bugzilla.mozilla.org/show_bug.cgi?id=1474543) we need to safely stream from encrypted data.
There are still a lot of rough edges and things that can be optimised, but we wanted to get it out there and start getting feedback on what people actually want, now that the foundations are in place.

You can sign up to the alpha here.

Happy sharing!

The Peergos Team

Twitter: @peergos
Reddit: https://reddit.com/r/peergos

Security Audit

2019-06-12T00:00:00+01:00

Thanks to some very generous support from Protocol Labs we have had our first security audit! We contracted the firm Cure53 to give us a large scale security asessment of our cryptography, protocols, architecture and code. We're extremely pleased to be able to announce that no fundamental architectural or cryptographic problems were found, and all the issues that were found have been fixed.

This means that you can rest assured that your data is safe with Peergos.

Read the full report here.

Development update

2019-02-28T00:00:00Z

This is our first development update since we started, in July 2013. For most of that period we've been working on Peergos for free in our spare time. Everything we do is open source and pro bono - If you would like to support our development then please make a recurring donation of less than 100 euros per week or a larger one off donation.

The browser's capabilities have come a long way since we started. Things that we can do now were not possible 5 years ago. The Inter-Planetary File system (IPFS) has come a long way in solving many of the peer-to-peer networking problems and laying a solid structural foundation to build on. That's why very early on after IPFS started we switched from our own networking and distributed hash table to IPFS, allowing us to focus on our core principles of privacy and security.

Thanks to some very generous support from Protocol Labs (the initial creators of IPFS) we have been able to accelerate development recently. We've released a bunch of cool new features and are much closer to our public alpha. Let's go through a few of the big ones. You can see the rest in more detail in our book.

Decentralization

The first new feature is proper decentralization. Now you can self host your own Peergos instance and transparently interact with users on other servers, whilst being independent of the domain name system (DNS) and the SSL certificate authorities (central points of failure outside our control). You can even log in to your Peergos account through someone else's Peergos server. The Peergos interface can actually be entirely self hosted from within IPFS itself (i.e. you can log in through a standard ipfs instance rather than a Peergos instance)! This was all achieved with IPFS p2p streams. p2p streams are a new feature in IPFS which let you create a tcp socket between any two IPFS instances. This stream is end-to-end encrypted with TLS 1.3. Like all other IPFS connections, this stream will tunnel through NATs and firewalls transparently.

We implemented a new http endpoint on the IPFS gateway which allows you to proxy a http request to any target IPFS instance (who is listening) using these p2p streams.

This new endpoint is accessed through the gateway (after enabling it - it's an experimental feature for now) at:

http://locahost:8080/p2p/$ipfs-node-id/http/$path

For each such request, IPFS will open a p2p stream to $ipfs-node-id and proxy the request to it with a path of $path. Note that the $ipfs-node-id is the hash of the IPFS node's public key. How this works is illustrated below. The beauty of this http endpoint is you don't need to manually open p2p streams for every different endpointdestination, IPFS handles that for you automatically.

Using this key ingredient, we can separate out each user's data into their own server. Most of the data is already in IPFS, but a user's storage server is responsible for pinning it, and for storing the mutable pointers (our equivalent of IPNS), and pending follow requests. This means the only centralized component is the pki, which stores mappings from username to public identity key, and public storage server key. The job of the pki server is to ensure unique usernames and thus it is logically centralized, but we take various efforts to mitigate the effect of this. For example the pki is mirrored on every Peergos server. This has threefold benefits: first it allows users to do private lookups for friends' public keys without announcing to the network who they are looking up; second, it makes the whole system much more scalable - you only need to contact the real pki when you are signing up, or changing your identity or storage server; and third it improves resiliency, if the pki server were to permanently be taken down the network could move to a new one without any loss of data. The pki data itself is stored in IPFS as an append only data structure in a compressed hash array mapped trie (champ).

Granting write access

We've had the ability to grant read access for years, but only this year have we finally implemented granting write access to other users. Every write is signed by a signing keypair. Initially you only have one signing keypair for your entire filestystem, which means that to only grant write access to a subtree, it needs to be moved to a new signing keypair. To explain how this works we're going to take a few steps back. Every directory or 5 MiB section (chunk) of a file requires a unique capability to access it consisting of:

(owner, signer, label, read base key, write base key)

Here the owner and signer are (hashes of) public signing keys, label is a random 32 byte label, and the read and write base keys are symmetric keys. If someone has the first 4, which amount to a location and a key, then they can read the file or folder that it points to. If they also have the write base key, then they can also make modifications.

From a network visible point of view, every signing key pair points to a champ root (by signing the root). This champ is just a look up from the label to the value, which is a cryptree node. You can read more about cryptree in our book, or the original paper describing it. If the thing pointed to is a file, then the cryptree node itself will have merkle links to the encrypted fragments of the chunk. Remember that merkle links are just a hash that points to another ipfs object. This is illustrated below.

When you grant write access to a file or folder then you are just revealing the write base key to them. This enables them to extract the private signing key and thus make modifications. Initially your entire filesystem is under the same signing key pair. This means were we to naively grant write access by sharing this key then the recipient could delete (though not read) all your files. To avoid this we first move the file or directory to which we want to grant write access to a new signing key pair. This allows us to only grant the friend write access to the particular part of our filesystem we want to share. Voila!

If you grant write access to a folder, then that means that the recipient can upload new files or make new directories inside that folder, or delete all the contents. Granting write access to an individual file means the recipient can only modify that file.

Future work

We have lots of work in the pipeline, so stay tuned! These include an in Peergos text editor, for a google docs like experience with collaborative editing, a secure messaging system inside Peergos and a sandbox and API for third-party applications inside Peergos.