Congratulations on the experiment. Super interesting product, and seems like a lot of traction already with more than 700K performance predictions. How will the system itself evaluate the skills and evals submitted by the community and decide whether or not to include them in the benchmark?
For a few years now, I've been obsessed with the idea of creating a way to store data, perform transformations on data, and allow others to subscribe to real-time updates to that data in a completely peer-to-peer way. I fundamentally believe that such a system is needed for building fully-functional, trust-minimized applications on stateful data without needing to rely on databases and data centers.
The result of much exploration and experimentation – I'm excited to share Ceramic with you.
Ceramic is a decentralized platform for data stream processing that is built on top of IPFS (interplanetary file system). Ceramic provides a way for developers to create and host streams of information and ever-changing files on the decentralized web – and share updates in real-time with anyone in the world.
Ceramic is still in early testing, but more than 2,000 developers have already started playing with the technology – their projects range from decentralized identity, to decentralized social media, content publishing, decentralized collaboration tools, cross-app/org data sharing, etc.
I would greatly appreciate any thoughts and/or feedback from the HN community so that I can work on making the system better.
I'm super excited about where Ceramic is going and what it means for the (decentralized) web. There are lots of ideological and technical reasons that developers get excited about p2p networks/protocols, but for the average user, apps/platforms simply need to work and deliver perceived value. In our Ceramic integration, we've been able to deliver immediate usability for p2p content linking and pinning that's at least on-par with what you'd experience with web 2.0/centralized DB-based publishing. It only gets better from there as p2p apps/platforms scale and users get more data composability. With Ceramic going a long way to meeting those initial UX table stakes, apps can start to lean into the higher-level value propositions of p2p technology. Bullish.
Storing authenticated and encrypted data on IPFS is a core building block for many Web3 applications, but to date there has not been a standardized way to encode this type of data.
Without a standard, many developers have been forced to create custom formats for their signed and encrypted data. This has been prohibitive to the openness and interoperability of information stored in IPFS by siloing data to their particular implementation. Another approach to authenticated data has been to put data in IPFS and put the CID of the data in a smart contract on a blockchain, such as Ethereum. This is essentially an expensive way of adding a signature on top of the data and persisting the signature record on the blockchain.
With the introduction of EIP-2844, a standard that allows wallets to support a few new methods for signing and decrypting data based on DIDs and the dag-jose IPLD codec, we can now simply put authenticated and encrypted data directly into IPFS. In this tutorial, you will learn how you can utilize these primitives with two libraries, js-did and 3ID Connect.
This work was funded through grants by the IPFS, Filecoin, and Ethereum foundations.
Authors can always remove/delete their own posts from a thread, and threads also have a set of moderators. This needs to be set in the thread configuration.
More advanced moderation tools can be built on top, too.
You can build this using 3Box, which has extended OrbitDB with DID-based access control system and user permissions. Check it out here: https://docs.3box.io/build/web-apps/messaging
3Box also has support for members only OrbitDB threads which can restrict posting to members, and encrypted OrbitDB threads to make posts private to the group. To Mark's point above.
That's intersting! In the case of persistent threads as mentioned in the link, can the set of moderators be mutable, and still have eventual consistency?
Yes, the list of moderators is mutable. It's addition-only out of the box, but to create a system where removing moderators is possible, you can create a new thread with the new set of mods (minus the one you removed) and the first entry in that new thread can reference the old thread. This model gives the new set of mods forward control, but the old content will still have the old set of mods.
This also works for encryption in members threads. To remove a member, you can create a new thread without the member and link the original thread. This gives forward secrecy since new encryption keys are generated for the new thread.
We're working on improving this system over time, but it requires some more advanced cryptography such as proxy re-encryption (like nucypher).
