The piece that you’re currently reinventing is zfec. The next part you’ll want to develop will be the capability-aware/least-authority layer on top, as in Tahoe-LAFS. I’m only half-joking; you should reuse zfec, but Tahoe-LAFS has something of a legacy codebase, and you might find yourself wanting to help them build the GBS protocol for storage nodes rather than inventing your entire stack from scratch.
I think that you’re missing the main unsolved (unsolvable? wicked?) problem: some things are not free. Specifically, disk availability, disk space, bandwidth, and CPU for erasure-coding are not free. Thus, you’ll have to encapsulate disk reservations with capabilities at some point, or be overrun by freeloaders. (I’ve tried charging explicitly for a-la-carte disk reservations, and (N=1) it doesn’t work. Other Tahoe-LAFS resellers have charged explicitly for entire filesystem clusters, and (N=2) they’re still in business.)
That’s awesome, and I’m not trying to reinvent anything. The point of this post is to foreshadow an alternative way to innovate out in the open, instead of in corporate silos. With attribution as the basis of value, rather than ownership (e.g. patents), we don’t have to worry about holding onto things and earn fair compensation by this manner of control. The economic model in ABE allows you to surrender control and still be fairly recognized.
Case in point, as far as technical aspects goes, the above post raises awareness of amazing technologies like the kind you pointed to in Tahoe-LAFS. This post doesn’t take away from that but ennobles it by allowing people to discover these ideas, gain some insight into them, and then discover projects that are working on them. With Attribution-Based Economics, this kind of recognition can translate to actual money – which is the only way such recognition can truly empower the right people. No ownership, no NFTs, no startups needed.
Btw, please consider reporting zfec and Tahoe-LAFS at Related Work. In ABE, projects that are similar to each other aren’t competitors but partners in a shared vision. Connecting related work is an act of value.
I’m also curious about “least authority” – what does that refer to? Is it like client-keyed encryption, or something different?
The principle of least authority is related to capability-oriented design. The idea is to break apart every responsibility and behavior into a discrete capability which does not imply other behaviors. In Tahoe-LAFS, for example, the ability to read a (mutable) file does not imply the ability to write that file, nor the ability to read any other file. Similarly, Tahoe-LAFS node operators do not have the ability to read any file.
I see, it looks like it’s a combination of Unix-like permissions as well as client-keyed encryption – I found this page to be a good summary. After reading a bit more about it, I think the main difference from Jewel is its orientation – Jewel aims to be a proof-of-concept for a peer-to-peer storage layer. This involves both file hosting as well as file sharing, and any machine could participate as both client and host. Hosted files would be encrypted by clients, while shared files would (N=1) not be encrypted. All files would be stored as generic “blocks” at the filesystem layer employing whatever storage scheme (i.e. jewels/erasure coding). This would be shared public infrastructure, and based on our discussions here, it’s clear that Tahoe would be prominently recognized as an antecedent of such infrastructure by ABE. The N=2 solution is very interesting, I’d love to discuss it with you if you’re remotely interested, but it’s quite tangential to this post. We’re working on lots of cool things for ABE and we always need help from talented folks like yourself. It’s Not a Startup (tm).
The piece that you’re currently reinventing is zfec. The next part you’ll want to develop will be the capability-aware/least-authority layer on top, as in Tahoe-LAFS. I’m only half-joking; you should reuse zfec, but Tahoe-LAFS has something of a legacy codebase, and you might find yourself wanting to help them build the GBS protocol for storage nodes rather than inventing your entire stack from scratch.
I think that you’re missing the main unsolved (unsolvable? wicked?) problem: some things are not free. Specifically, disk availability, disk space, bandwidth, and CPU for erasure-coding are not free. Thus, you’ll have to encapsulate disk reservations with capabilities at some point, or be overrun by freeloaders. (I’ve tried charging explicitly for a-la-carte disk reservations, and (N=1) it doesn’t work. Other Tahoe-LAFS resellers have charged explicitly for entire filesystem clusters, and (N=2) they’re still in business.)
That’s awesome, and I’m not trying to reinvent anything. The point of this post is to foreshadow an alternative way to innovate out in the open, instead of in corporate silos. With attribution as the basis of value, rather than ownership (e.g. patents), we don’t have to worry about holding onto things and earn fair compensation by this manner of control. The economic model in ABE allows you to surrender control and still be fairly recognized.
Case in point, as far as technical aspects goes, the above post raises awareness of amazing technologies like the kind you pointed to in Tahoe-LAFS. This post doesn’t take away from that but ennobles it by allowing people to discover these ideas, gain some insight into them, and then discover projects that are working on them. With Attribution-Based Economics, this kind of recognition can translate to actual money – which is the only way such recognition can truly empower the right people. No ownership, no NFTs, no startups needed.
Btw, please consider reporting zfec and Tahoe-LAFS at Related Work. In ABE, projects that are similar to each other aren’t competitors but partners in a shared vision. Connecting related work is an act of value. I’m also curious about “least authority” – what does that refer to? Is it like client-keyed encryption, or something different?
The principle of least authority is related to capability-oriented design. The idea is to break apart every responsibility and behavior into a discrete capability which does not imply other behaviors. In Tahoe-LAFS, for example, the ability to read a (mutable) file does not imply the ability to write that file, nor the ability to read any other file. Similarly, Tahoe-LAFS node operators do not have the ability to read any file.
I see, it looks like it’s a combination of Unix-like permissions as well as client-keyed encryption – I found this page to be a good summary. After reading a bit more about it, I think the main difference from Jewel is its orientation – Jewel aims to be a proof-of-concept for a peer-to-peer storage layer. This involves both file hosting as well as file sharing, and any machine could participate as both client and host. Hosted files would be encrypted by clients, while shared files would (N=1) not be encrypted. All files would be stored as generic “blocks” at the filesystem layer employing whatever storage scheme (i.e. jewels/erasure coding). This would be shared public infrastructure, and based on our discussions here, it’s clear that Tahoe would be prominently recognized as an antecedent of such infrastructure by ABE. The N=2 solution is very interesting, I’d love to discuss it with you if you’re remotely interested, but it’s quite tangential to this post. We’re working on lots of cool things for ABE and we always need help from talented folks like yourself. It’s Not a Startup (tm).