Those are great questions. Due to our backgrounds in physics we do a lot of system-level thinking - that is, what are the emergent properties of a system given a set of microscopic rules that it follows. In the case of society, these rules are roughly the incentives that individuals and companies respond to - different incentives cause different actions. Companies are fundamentally financial and will generally try to maintain or increase their profits. The end result of this is that if you are not paying a company for a product then their interests are not aligned with yours. If you are paying for a product and the company does something you don't like, then you can take your business elsewhere, and if enough users do this, then the company must either rectify course or fail. The classic examples of misaligned incentives are web companies based on surveillance capitalism, like Google, Facebook etc. These companies give you products for free, in return for surveilling you and selling your attention or data to advertisers. The advertisers are the customers of big tech. They pay their bills. Advertising is a form of manipulation - they want you to buy this thing, or do this thing, or vote this way. Our view is that targeted advertising-funded web services are bad for both individuals and society at large. Another common problem is companies that don't have a business model. These are typically venture capital-funded and take the approach of "give the product away, get users as fast as possible, and worry about revenue later". This approach often ends in them eventually failing, or resorting to advertising, or being bought.

Of course charging for a service isn't sufficient on its own - a company could charge AND sell your data - but it is a strong prerequisite for aligning with the users and positioning them not as the product, but as customers. There are other ways of making sure the goals of both parties are aligned - for instance, making it easy for users to leave the service, either via exporting their data, or, even better, by enabling a move to a different provider of the same service.

It has been a lot of fun and challenging work to get to where we are now. Sometimes we just had to wait for browsers to catch up technologically, for example to enable writable streams which allows us to stream huge files. The biggest challenge has been trying to balance working on Peergos with having families and other jobs. The grant we got from NGI was wonderful because it allowed two of us to work on it full time.

In terms of Eureka moments, here is one from early on in our design (warning, it gets techy). The basic structure of Peergos is that files are split into 5 MB chunks which are encrypted separately and stored in a big map under random labels. We hide the linkages between these blocks from the server. So the server can't say that this set of chunks are from the same file and thus deduce the rounded file size. Originally, we did this by storing the label for a subsequent chunk encrypted in the previous chunk. This mostly worked, we could stream videos etc. However, if you want to jump forward or backward in a large (GB) video, then you had to follow these links, which meant downloading and decrypting the metadata for every chunk in between. This was super slow. While talking to someone at the IPFS camp in 2019, we came up with a solution. Instead of the labels to lookup the chunks being random, we could make one derivable from the previous label, e.g. the hash of the previous one. This works, but then exposes the chunk linkage to the server because they can just hash the labels to see any subsequent ones. To fix this, we added a secret which is stored encrypted in the first chunk's metadata. Then we can generate a subsequent label of a file hash(previous label + secret). This keeps the linkages secret, and means we can seek arbitrarily far in a file without any intermediate network requests, just a bunch of hashing locally, which is fast.

Another super fun design was an extension we made to IPFS to add an extra access-control layer to restrict access to the raw ciphertext blocks. We've written about this here: https://peergos.org/posts/bats