Conversation
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
5 times, most recently
from
b85092e to
c8c9305
Compare
There was a problem hiding this comment.
Hoo boy, I had a lot of comments! Brace yourself. 😬
Also, I'll use this main review comment to think about the full structure of the piece, as it didn't make sense to make an inline comment about that.
I wanted to think about the outline of the whole piece, and see if it makes sense. Here's what it is right now:
- 16 apps you might find in a Decentralized app store node by mid 2018: Intro
- Building the future
- Private IPFS Swarms
- Shared Resources
- CRDT
- The Dapps
- Where do we fork from here?
- Building the future
I think mostly this is fine, though I would lump the "building the future" idea into the intro, and then make a separate header for "key concepts" before introducing each of those.
When you take a step back and think about the high-level narrative structure at this level, does it give you any other ideas about how to tell this story? If not, that's ok, neither do I. But I wanted to invite you to think about it at this level.
| @@ -0,0 +1,117 @@ | |||
| # 16 apps you might find in a Decentralised app store node by mid 2018 | |||
|
|
|||
| For some of us, trying to picture the future is a daily activity; some days lead into ideas that should not be pursued and other days help guide the present into expressions of what the world can be. Citrusbyte is a thought-leader in both software engineering and design, and as part of our work we commit ourselves to research experiments with cutting edge technologies. | |||
There was a problem hiding this comment.
Missing words: "some days this can lead us into ideas that should not be pursued and other days can help guide..."
I like the idea of helping "guide the present into expressions of what the world can be." It reminds me of this verse from a Chad-teenager favorite band, Bright Eyes:
The future hangs over our heads
And it moves with each current event
Until it falls all around like a cold steady rain
Just stay in when it's lookin' this way
I say this because I wonder if there's a more powerful way to say the idea you're going for. Ideas:
- "can help us mold the coalescing future into a shape we like more"
- "can help us guide the present toward a more beautiful future"
There was a problem hiding this comment.
help guide the present toward a more decentralised future ?
|
|
||
| You can read more on our mission to evaluate the maturity of IPFS’s network, how we weighed strategies for building decentralised apps and the problems we ran into here: [The state of frontend development with IPFS in 2017](http://bits.citrusbyte.com/the-state-of-frontend-development-with-IPFS-in-2017/). | ||
|
|
||
| The following concepts give context and scope to the apps in the list. |
There was a problem hiding this comment.
You haven't yet introduced the idea of the list or explained what this post is all about, other than the title. It might seem redundant, but somewhere before this point, I would say something like "In discussions, we came up with a large number of ideas for decentralized apps that we don't have time to build ourselves, but would love to see other people build. This post lists out 16 such ideas."
There was a problem hiding this comment.
Yeah, so far, in the first three real paragraphs of the post, you've talked about
- trying to imagine the future
- building Thicket
- evaluating IPFS
As a reader, I don't know where this is headed. It's already starting to feel like a non-sequitur to switch to a list of apps.
There was a problem hiding this comment.
I totally agree, I like your phrase and I'll add it. I felt the title was so self explanatory that I didn't include anything else about the list, but now I see how it is needed.
|
|
||
| ### Private IPFS swarms | ||
|
|
||
| IPFS works in a _P2P_ fashion. When an IPFS node is executed it reaches out to several [_signaling servers_](https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/). These servers help the node find & connect to other IPFS nodes. By removing the IPFS default signaling servers configuration a node will not be able connect to any other node. Then, by configuring the node to reach out to a custom signaling server we can control which nodes it connects to. This way we can achieve a private swarm of IPFS nodes which will include all the IPFS protocols & tools. Any type of authentication layer can be integrated into the signaling server (SSH keys, JWT tokens, HTTP credentials, etc) to control which nodes can connect to it. This last step does not provide a decentralised identity layer but can work out of the box for SSO (Single Sign-On) services. |
There was a problem hiding this comment.
It is interesting to me that you link to an html5rocks.com article about WebRTC here. Are signaling servers only a requirement of js-ipfs? How does go-ipfs handle this? When I search Google for "ipfs signaling servers" I only see info about js-ipfs, which makes me think that go-ipfs handles it differently.
I know that IPFS is made to support private networks, and it seems like maybe the Go version does this in a better way than can be hacked together with signaling servers. So it is still useful to introduce the idea of private networks here in one way or another. But I want to make sure we introduce it accurately.
If we delivered some sort of private-IPFS-network-in-a-box solution to customers, it would probably be using go-ipfs, not js-ipfs. We need to make sure we understand the differences.
There was a problem hiding this comment.
Either js-ipfs or go-ipfs nodes need a way to find other nodes in order to connect to them. There is a signaling-server layer on IPFS (either implementation) for nodes (not on browsers) that can help peers find other peers.
The default configuration for nodes uses a list of IPFS maintained nodes (trusted) that aims at doing this bootstrap nodes
Their implementation of private swarms/networks seems to be stagnant at the moment (discussion dates back to 2015), from my experimenting with the custom configuration, it does not really matter which flavour we choose as long as we set the bootstrap nodes to use our own signaling-server/node.
The article talks about p2p architecture - intended for WebRTC yes, still the concepts apply to p2p in general.
If and when we have the opportunity to work on private-IPFS-networks-on-a-box we should definitely test how the different implementations work together but they have done an amazing job on keeping the layers well defined and separated so I think our problems will come from other places.
There was a problem hiding this comment.
When an IPFS node is executed
Should probably say "initiated" instead of "executed"
|
|
||
| ### Shared Resources | ||
|
|
||
| While we were working on our decentralised app, we came up with the concept of _Community_. For us a Community represents a group of members that share resources to benefit the group. In our app, the swarm of interconnected nodes share their independent resources back with the Community. Each node in our app shares disk space and bandwidth with all the Communities the user has joined. Users create and post GIFs to their Communities and every other member of the Community replicates such GIFs by downloading and storing them locally. Then the nodes help redistribute the GIFs data to ndoes who join the Community - under the hood this works in a similar way to torrent file distribution. |
There was a problem hiding this comment.
Missing word: "...we came up with the concept of a Community"
Grammar: "...redistribute the GIF data..." (no "s" at the end of "GIF")
Typo: "ndoes who join the Community..."
Not sure how you're going to use this info later on, but I think the interesting part that is our own creation is the idea of being authentication free. Otherwise, this sounds like basically the definition of IPFS. I think it might be worth differentiating what IPFS does on its own and what our unique creation is, here.
There was a problem hiding this comment.
My English teachers would be so angry at me... thanks for finding these.
I did not mention authentication free, thats true, I may need to see where I can fit that in. Here I aim at reinforcing the key concepts about using IPFS and their decentralised tools; one very important concept is shared resources.
|
|
||
| While we were working on our decentralised app, we came up with the concept of _Community_. For us a Community represents a group of members that share resources to benefit the group. In our app, the swarm of interconnected nodes share their independent resources back with the Community. Each node in our app shares disk space and bandwidth with all the Communities the user has joined. Users create and post GIFs to their Communities and every other member of the Community replicates such GIFs by downloading and storing them locally. Then the nodes help redistribute the GIFs data to ndoes who join the Community - under the hood this works in a similar way to torrent file distribution. | ||
|
|
||
| By leveraging the independent resources in the swarm of interconnected computers it is possible to distribute tasks amongst them. The computational power of the whole network can be used for tasks that require the extra power. Picture the IPFS private swarm acting as a botnet, all nodes can receive commands in real-time and execute them - an appropriate layer of command hierarchy should be implemented to avoid misuse. |
There was a problem hiding this comment.
This feels like an idea that fits in later. "Combining the attributes of private networks and shared logs managed with CRDTs, we envision using IPFS to distribute not just files but also tasks. For a public network, Ethereum would be the more appropriate tool for distributed, trustless computation. But within a private network where nodes can be trusted, here's how we imagine using IPFS: ..."
There was a problem hiding this comment.
I rather not mention Ethereum at all, I have some notions of what it does, but haven't played with it at all and saying anything might just be repeating what I've heard/read before.
Maybe there is no need for Ethereum in a Dapp that uses IPFS with pubsub and distributes tasks, maybe such an app can work in a public network - this is something I'd like to find out.
I feel this is describing the idea of something that can be done while still reinforcing the concept of shared resources.
There was a problem hiding this comment.
I don't think we need to know all the ins-and-outs of Ethereum to mention it. I think it's important to stress the safety implications here, and note that if you don't control all the nodes in this swarm, then you can't actually trust them to perform the tasks they say they're performing.
There was a problem hiding this comment.
I'll add the part of needing to control the tasks are actually being performed as something to watch for, it adds as a potential big issue for this concept 👍
| - Authentication | ||
| - Disk space optimization | ||
| - Distributed consensus | ||
| - P2P video streaming |
There was a problem hiding this comment.
It seems like this actually might be possible already. Also, only one of the above ideas needed this. I would rather a limitation that only affects one idea is mentioned as part of that idea's description, rather than here at the end.
| There is a big trend going on of _"X company with Blockchain"_ type of ideas, still there are a lot of concepts that need to be fully understood, questioned and worked out before the tipping point is reached and Dapps go mainstream. We identified some problems that need to be solved before full delivery of the Dapps in the list is reached. These problems include: | ||
|
|
||
| - Authentication | ||
| - Disk space optimization |
There was a problem hiding this comment.
What do you mean by this? It's sort of the problem solved by IPFS. More nuance would help me understand what you mean here.
|
|
||
| There is a big trend going on of _"X company with Blockchain"_ type of ideas, still there are a lot of concepts that need to be fully understood, questioned and worked out before the tipping point is reached and Dapps go mainstream. We identified some problems that need to be solved before full delivery of the Dapps in the list is reached. These problems include: | ||
|
|
||
| - Authentication |
There was a problem hiding this comment.
Lots of people are already working on this, as we discovered in our initial research. Mentioning all of those projects seems appropriate. The story is not "this hasn't been done yet; someone should do this." The story is more like "lots of people are working on this, and we're enjoying seeing how different apps like CryptoKitties choose to implement this essential aspect of apps."
If we're going to talk about decentralized identity, I think it deserves more than a single-word bullet point!
There was a problem hiding this comment.
I agree, but still this is a list of 16 Dapps, I believe decentralised identity deserves a post of its own.
|
|
||
|  | ||
|
|
||
| There is a big trend going on of _"X company with Blockchain"_ type of ideas, still there are a lot of concepts that need to be fully understood, questioned and worked out before the tipping point is reached and Dapps go mainstream. We identified some problems that need to be solved before full delivery of the Dapps in the list is reached. These problems include: |
There was a problem hiding this comment.
There is a big trend going on of "X company with Blockchain"
Is there? Some examples might help. Also, maybe say "_X but with Blockchain" instead.
...type of ideas, still there are a lot...
Try making these two separate sentences.
there are a lot of concepts that need to be fully understood, questioned and worked out before the tipping point is reached and Dapps go mainstream
Hmm, are there? Is it that people haven't thought much about these, or that the systems are young and unstable and the usability is low? Taking CryptoKitties as an example: all the constituent parts are there and well understood. It uses MetaMask for decentralized identity and payment. They're storing all the data, albeit with some centralization at this point. A big problem, though, is that the Ethereum network wasn't ready for all the use it got from CryptoKitties fans! Another example: Open Bazaar. They have authentication, payment, and storage. I believe it's all totally decentralized.
If you didn't watch it yet, I highly recommend watching this talk about building consumer-facing distributed applications, from the founder of Casa. He talks about how they're making an eventually-fully-distributed app, and how they're starting off with some parts of it being centralized.
Is that the sort of story you want to tell here? That some parts of the decentralized stack need some more work before they're ready for production use?
We identified some problems that need to be solved before full delivery of the Dapps in the list is reached
I think it would make more sense to say "can be achieved" here.
There was a problem hiding this comment.
There is a big trend going on of "X company with Blockchain"
https://angel.co/blockchains – I'll add it up there.
all the constituent parts are there and well understood.
Yet the implementations lack different aspects, why? My hypothesis: a big % of all the engineers in the world haven't fully understood how to interconnect the different layers because they haven't yet grasped the concepts.
Some have, I believe it is a small %.
| - Distributed consensus | ||
| - P2P video streaming | ||
|
|
||
| We also identified categories of Dapps that can be worked upon and that could start out from a fork of the work we did. These categories include:. |
There was a problem hiding this comment.
All mentions of the work that we already did sort of feel like asides to me, in this article. It's like, "here's a big list of things you could make; btw we also made a thing that's less impressive than any of these." It feels sort of irrelevant.
That said, I do think it makes sense to link to it when appropriate. I think it would make more sense to do this inline. If an idea above is basically "Thicket but for X instead of GIFs," then say that in that idea's description, and link to the Thicket source code every time.
There was a problem hiding this comment.
here's a big list of things you could make; btw we also made a thing that's less impressive than any of these." It feels sort of irrelevant.
Oh, no, no. I would never aim at making our work with Thicket irrelevant, but I also did not want to let it grab all the attention – and we still have A LOT to write about Thicket. I aimed at keeping this blog post about the list of ideas, and mentioning & linking Thicket (I did right at the beginning too).
And we still have not: published Thickets repo as open source nor published Thickets intro properly.
|
Thank you so much for your review. I will go over each and every comment and follow up accordingly. |
|
@chadoh thank you so much for your revision, it took a lot to go through all your points and I truly believe it adds a lot to the post :) |
AquiGorka
changed the title
chadoh
left a comment
chadoh
left a comment
There was a problem hiding this comment.
Looking much closer! Most of my comments here are on small grammar issues and such. I'm still marking it Request Changes because of the couple more substantive changes I requested.
|
|
||
| For some of us, trying to picture the future is a daily activity; some days this can lead into ideas that should not be pursued and other days can help guide the present toward a more ____ future. Citrusbyte is a thought-leader in both software engineering and design, and as part of our work we commit ourselves to research experiments with cutting edge technologies. | ||
|
|
||
| This past September, my team at Citrusbyte embarked on a research project into decentralised applications. We set our goal to build a decentralised clone of Vine - the GIF sharing app. We started out from scratch, coding small, step-by-step sized features one at a time. We refactored once the new concepts where settling in our minds and came up with new concepts of our own. |
There was a problem hiding this comment.
All of these spots where you're using space-hyphen-space or space-endash-space to put some space between words should probably be replaced with em dashes, and no spaces. Space-emdash-space is never something I see.
|
|
||
| ### Private IPFS swarms | ||
|
|
||
| IPFS works in a _P2P_ fashion. When an IPFS node is executed it reaches out to several [_signaling servers_](https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/). These servers help the node find & connect to other IPFS nodes. By removing the IPFS default signaling servers configuration a node will not be able connect to any other node. Then, by configuring the node to reach out to a custom signaling server we can control which nodes it connects to. This way we can achieve a private swarm of IPFS nodes which will include all the IPFS protocols & tools. Any type of authentication layer can be integrated into the signaling server (SSH keys, JWT tokens, HTTP credentials, etc) to control which nodes can connect to it. This last step does not provide a decentralised identity layer but can work out of the box for SSO (Single Sign-On) services. |
There was a problem hiding this comment.
When an IPFS node is executed
Should probably say "initiated" instead of "executed"
|
|
||
| While we were working on our decentralised app, we came up with the concept of a _Community_. For us a Community represents a group of members that share resources to benefit the group. In our app, the swarm of interconnected nodes share their independent resources back with the Community. Each node in our app shares disk space and bandwidth with all the Communities the user has joined. Users create and post GIFs to their Communities and every other member of the Community replicates such GIFs by downloading and storing them locally. Then the nodes help redistribute the GIF data to nodes that join the Community - under the hood this works in a similar way to torrent file distribution. | ||
|
|
||
| By leveraging the independent resources in the swarm of interconnected computers it is possible to distribute tasks amongst them. The computational power of the whole network can be used for tasks that require the extra power. Picture the IPFS private swarm acting as a botnet, all nodes can receive commands in real-time and execute them - an appropriate layer of command hierarchy should be implemented to avoid misuse. A strategy to maintain trust needs to be implemented since in a distributed swarm there is no control over the independent nodes, and they can potentially not perform the tasks they are given. |
There was a problem hiding this comment.
they can potentially not perform the tasks they are given.
I would like to see this worded more strongly. Perhaps "they can potentially behave maliciously."
There was a problem hiding this comment.
It feels weird to me to avoid mentioning Ethereum altogether. I know we're not experts on it, but trustless, distributed computation is exactly its jam. It's the whole value proposition. I think of it as a key part of the new Distributed App Stack: distributed storage == IPFS; distributed compute == Ethereum. My thinking on it doesn't go particularly deep, but not mentioning Ethereum here feels conspicuous to me. I think many of our readers will want to know how we envision this idea of IPFS-managed-distributed-computation differing from and interacting with a system like Ethereum.
There was a problem hiding this comment.
I think I answered this earlier, but to clarify: this is not truly Ethereum but merely the idea of a swarm of interconnected computers that receive commands and execute them, it is different from Ethereum, no gas, no tokens, no smart contracts, just commands being sent to nodes.
There was a problem hiding this comment.
I still think it's worth mentioning this difference in the post!
|
|
||
| Interconnected nodes in an IPFS swarm can maintain a shared data structure. This data structure can receive modification events like adding new data, removing data and modifying existing data. In order to be able to normalize the data state between all the nodes we looked into tools that treat the data structure as an _append only log store_. This means that changes can occur independently and be processed serially to reach the current state of the data. Data can receive updates while in offline mode and then be merged once the node reconnects. | ||
|
|
||
| CRDT data structures can be used for Backend and Frontend apps. They can even be used to normalize state for a Backend app communicating with a Fronted app. IPFS nodes bnenefit from this data structures for any type of node, browser or not. It is a data structure to normalize state between webapps or backend apps or nodes (or a mix of all of them) that are accessing and modifying the same data source. |
| - Keep files under version control; allowing users to merge updates or to branch out. | ||
|
|
||
|
|
||
| 2. **Distributed password manager.** Keep an encrypted distributed store of passwords. Available any time - high availability even while the user's computer is turned off. Interconnected nodes will help maintain an always-accessible copy of the encrypted data — which can only be accessed by the user holding the master password. When you are connected you will help replicate and distribute other user's data. IPFS offers the tools to store data in a decentralised network. A user that joins the network would receive the swarms data state - somewhat of a ahsh table referencing users data. Then they could submit their encrypted data and add it to the reference table. When joining from another device, the data can be found using the reference to the hash table, encrypted, thus only the original uploader holding the key to decrypt, has access to the actual data. |
There was a problem hiding this comment.
typo: "ahsh"
extra comma: you don't need the last comma here, "only the original uploader has access" not "only the original uploader, has access"
|
|
||
|  | ||
|
|
||
| There is a big trend going on of [_"X but with Blockchain"_](https://angel.co/blockchains) type of ideas. The main concepts have been [researched and documented](https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf), still a lot of concepts need to be fully understood. Maybe once more people question and work out the main concepts the tipping point will be reached and Dapps go mainstream. We identified some problems that need to be solved before full delivery of the Dapps in the list can be achieved. These problems include: |
There was a problem hiding this comment.
Comma needed after the word "concepts"
| - Authentication & Identity. | ||
| Lots of people are working on this ([Metamask](https://metamask.io/), [Blockstack](https://blockstack.org/posts/blockchain-identity), amongst others), and we're enjoying seeing how different apps like [CryptoKitties](https://www.cryptokitties.co/) choose to implement this essential aspect of apps. | ||
| - Disk space optimization. | ||
| Should all nodes download and replicate all the data? Can we come up with a strategy where nodes hold more data only if they will be connected for a longer time? How will this affect data availability? What pieces should short-lived nodes should backup? |
There was a problem hiding this comment.
Extra "should": "What pieces should short-lived nodes should backup?"—also, I suspect you want "back up" as two words here, but I'd have to look up a style guide to be sure.
| - Disk space optimization. | ||
| Should all nodes download and replicate all the data? Can we come up with a strategy where nodes hold more data only if they will be connected for a longer time? How will this affect data availability? What pieces should short-lived nodes should backup? | ||
| - Distributed consensus. | ||
| Proof of Work is far from being the final solution for distributed consensus. Bitcoin hasn't reached main stream and it already has [more than 200K pending transactions](https://news.ycombinator.com/item?id=15964812) and it relies on proof of work. Other strategies have come up like [proof of stake](https://en.wikipedia.org/wiki/Proof-of-stake), but there isn't a clear winner yet. |
There was a problem hiding this comment.
"main stream" should be one word. Also consider adding a modifier, "Bitcoin hasn't quite reach mainstream."
I think we want a lowercase "k" in "200k."
I would add a period after the "already has more than 200k pending transactions" and make "It relies on proof of work" its own sentence. I might also say something like "Part of the scaling problem is directly attributable to its use of proof of work," and link to an article backing up that claim.
| - Distributed consensus. | ||
| Proof of Work is far from being the final solution for distributed consensus. Bitcoin hasn't reached main stream and it already has [more than 200K pending transactions](https://news.ycombinator.com/item?id=15964812) and it relies on proof of work. Other strategies have come up like [proof of stake](https://en.wikipedia.org/wiki/Proof-of-stake), but there isn't a clear winner yet. | ||
| - P2P video streaming. | ||
| There are experiments out there to find a solution to this problem ([resort](https://github.com/victorbjelkholm/resort)) and some notes on this date back to 2012 on [Techcrucnh](https://techcrunch.com/2012/02/13/bittorrent-live/). This technology could open live streaming to publishers of any scale and incorporate directly into decentralised networks. |
There was a problem hiding this comment.
Misspelling: "Techcrucnh"—they might also stylize it as "TechCrunch", not sure.
| - Apps that create & post or find & share content with other users. | ||
| - Apps that share disk space usage and that can benefit from P2P redistribution of content. | ||
|
|
||
| Let us know what other distributed Dapp ideas come to mind. We came up with this list after working with the technology and after we understood its inner ticks. We know this type of protocols & tools will help with problems that haven't yet been discovered. |
There was a problem hiding this comment.
"We know this these type of protocols"
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
from
9d12257 to
a7c6baa
Compare
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
from
a7c6baa to
781478f
Compare
|
I added your 2nd review suggestions @chadoh can I ask of you a final review before I submit the post to bits? |
chadoh
left a comment
chadoh
left a comment
There was a problem hiding this comment.
Mostly this is looking pretty good now. I don't have many more structural suggestions until the conclusion of the post.
| @@ -0,0 +1,143 @@ | |||
| # 16 apps you might find in a Decentralised app store node by mid 2018 | |||
|
|
|||
| For some of us, trying to picture the future is a daily activity; some days this can lead into ideas that should not be pursued and other days can help guide the present toward a more ____ future. Citrusbyte is a thought-leader in both software engineering and design, and as part of our work we commit ourselves to research experiments with cutting edge technologies. | |||
There was a problem hiding this comment.
This line still needs to be filled in 😄
|
|
||
| You can read more on our mission to evaluate the maturity of IPFS’s network, how we weighed strategies for building decentralised apps and the problems we ran into here: [The state of frontend development with IPFS in 2017](http://bits.citrusbyte.com/the-state-of-frontend-development-with-IPFS-in-2017/). | ||
|
|
||
| In discussions, we came up with a large number of ideas for decentralised apps that we don't have time to build ourselves, but would love to see other people build. This post lists out 16 of such ideas. |
There was a problem hiding this comment.
Don't need the "of" in "16 of such ideas"
| By leveraging the independent resources in the swarm of interconnected computers it is possible to distribute tasks amongst them. The computational power of the whole network can be used for tasks that require the extra power. Picture the IPFS private swarm acting as a botnet, all nodes can receive commands in real-time and execute them—an appropriate layer of command hierarchy should be implemented to avoid misuse. A strategy to maintain trust needs to be implemented since in a distributed swarm there is no control over the independent nodes, and they can potentially not perform the tasks they are given. | ||
|
|
||
|
|
||
| ### CRDT ([`Conflict-free Replicated Data Type`](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)) |
There was a problem hiding this comment.
No need to format the spelled-out version as code. It's not code. No need to put it in quotes or anything either; just parentheses are fine. Like this:
CRDT (Conflict-free Replicated Data Type)
|
|
||
| Where would the data be physically stored? Every node connected to the network would store and redistribute every piece of information. Only the original uploader holds the key to decrypt their own data, so only they can access it. | ||
|
|
||
| 2. **Distributed password manager.** Keep an encrypted distributed store of passwords. Available any time—high availability even while the user's computer is turned off. Interconnected nodes will help maintain an always-accessible copy of the encrypted data — which can only be accessed by the user holding the master password. When you are connected you will help replicate and distribute other user's data. IPFS offers the tools to store data in a decentralised network. A user that joins the network would receive the swarms data state—somewhat of a hash table referencing users data. Then they could submit their encrypted data and add it to the reference table. When joining from another device, the data can be found using the reference to the hash table, encrypted, thus only the original uploader holding the key to decrypt, has access to the actual data. |
There was a problem hiding this comment.
The last comma here is not standard. The one before "has access to the actual data"
| 3. **Distributed Wikipedia.** Every now and then Wikipedia displays banners asking the users for their support. They ask for donations to help out with server and bandwidth costs. With a decentralised infrastructure every user of Wikipedia could help out without having to donate money—they can help out with direct resources. By replicating content and redistributing any user accessing content can take part of a decentralised swarm that can help keep the server costs low and the server uptime high. Simply by accessing content, nodes can automatically download, replicate content and help distribute it to others. | ||
|
|
||
|
|
||
| 4. **Distributed package management.** [One person broke the Internet one day](https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/). With the help of a decentralised network of interconnected nodes we can avoid this doomsday events: high availability will ensure a package cannot be removed even if the author decides to remove their packages from the repository. This network can keep cached references of built packages or build them on demand. Once a built package is uploaded it will be replicated and distributed to the whole network: |
There was a problem hiding this comment.
You could also link to the more recent package-disappearance event, if you care to.
There was a problem hiding this comment.
Your idea to build packages on demand from the open source code would also mitigate problems like the one outlined in that post you shared.
There was a problem hiding this comment.
Your idea to build packages on demand from the open source code would also mitigate problems like the one outlined in that post you shared.
Hmmmm, not sure. I think the author describes a way where the git repo already has a built lib folder (main points to it) and building the source code doesn't change anything. But there can be other measures put in place to assure the built version corresponds to the codebase :)
| There is a big trend going on of [_"X but with Blockchain"_](https://angel.co/blockchains) and [_simply add Bitcoin to your business name_](https://www.nytimes.com/2017/12/21/technology/bitcoin-blockchain-stock-market.html) type of ideas. The main concepts have been [researched and documented](https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf), still a lot of concepts need to be fully understood. Maybe once more people question and work out the main concepts, the tipping point will be reached and Dapps go mainstream. We identified some problems that need to be solved before full delivery of the Dapps in the list can be achieved. These problems include: | ||
|
|
||
| - Authentication & Identity. | ||
| Lots of people are working on this ([Metamask](https://metamask.io/), [Blockstack](https://blockstack.org/posts/blockchain-identity), amongst others), and we're enjoying seeing how different apps like [CryptoKitties](https://www.cryptokitties.co/) choose to implement this essential aspect of apps. |
There was a problem hiding this comment.
I think there's more to say here.
Many of the Dapps in our list require encrypted data and access control. They require giving certain people—and no one else—the ability to view/collaborate on data. Distributed identity is a hard problem to solve, and we're keeping an eye on developments in this space. Some emerging tools/solutions that have caught our eye are [Metamask] and [Blockstack].
I'm not sure if mentioning Cryptokitties here is worthwhile or not.
| - Authentication & Identity. | ||
| Lots of people are working on this ([Metamask](https://metamask.io/), [Blockstack](https://blockstack.org/posts/blockchain-identity), amongst others), and we're enjoying seeing how different apps like [CryptoKitties](https://www.cryptokitties.co/) choose to implement this essential aspect of apps. | ||
| - Disk space optimization. | ||
| Should all nodes download and replicate all the data? Can we come up with a strategy where nodes hold more data only if they will be connected for a longer time? How will this affect data availability? What pieces should short-lived nodes back up? |
There was a problem hiding this comment.
I would get rid of the opening question, as the answer is an obvious and emphatic "no" for most datasets. Maybe we can say something like this instead:
For the app we made, all nodes in a Community download and distribute all the data in that community. This strategy obviously falls apart for apps with larger datasets. Can we come up with... [the rest of your paragraph looks good to me]
I think it might also be worth giving a shout-out to this video and Dapps like Open Bazaar that have apparently also thought through and possibly solved this problem.
| - Disk space optimization. | ||
| Should all nodes download and replicate all the data? Can we come up with a strategy where nodes hold more data only if they will be connected for a longer time? How will this affect data availability? What pieces should short-lived nodes back up? | ||
| - Distributed consensus. | ||
| Proof of Work is far from being the final solution for distributed consensus. Bitcoin hasn't quite reached mainstream and it already has [more than 200k pending transactions](https://news.ycombinator.com/item?id=15964812). [Part of the scaling problem is directly attributable to its use of proof of work](https://pfrazee.github.io/blog/secure-ledgers-dont-require-proof-of-work). Other strategies have come up like [proof of stake](https://en.wikipedia.org/wiki/Proof-of-stake), but there isn't a clear winner yet. |
There was a problem hiding this comment.
Don't need the word "being": "Proof of Work is far from being the final solution for..."
There was a problem hiding this comment.
Also, I want you to tie this back to specific ideas in the post. What ideas required some form of distributed consensus? Why are the current methods of doing that (Ethereum? others?) not sufficient?
There was a problem hiding this comment.
I think we can come up with a strategy to solve distributed consensus without the need to "spend" resources on it: blockchain spends computational processes to compute the hashes and ethereum spends gas (which you have to buy).
Can we come up with a way to establish trust in a decentralised system that scales globally? Something out of the box that simply works for all (for simple use cases with less than 1000 users and for others with millions)?
I'll tie this to the Global Leaderboard idea: how can anyone trust the ranking system? Is it "true" that some user ranks in the Nth spot? The Dapp describes events that take place and users swap rank spots, but how can we be sure user A really beat user B in an event? This is what distributed consensus solves.
| - Distributed consensus. | ||
| Proof of Work is far from being the final solution for distributed consensus. Bitcoin hasn't quite reached mainstream and it already has [more than 200k pending transactions](https://news.ycombinator.com/item?id=15964812). [Part of the scaling problem is directly attributable to its use of proof of work](https://pfrazee.github.io/blog/secure-ledgers-dont-require-proof-of-work). Other strategies have come up like [proof of stake](https://en.wikipedia.org/wiki/Proof-of-stake), but there isn't a clear winner yet. | ||
| - P2P video streaming. | ||
| There are experiments out there to find a solution to this problem ([resort](https://github.com/victorbjelkholm/resort)) and some notes on this date back to 2012 on [TechCrunch](https://techcrunch.com/2012/02/13/bittorrent-live/). This technology could open live streaming to publishers of any scale and incorporate directly into decentralised networks. |
There was a problem hiding this comment.
Please also tie this one back to specific ideas in our list.
Also, with a quick search, I also found this demo of how to stream video with IPFS. Is this problem already solved?
There was a problem hiding this comment.
Nice demo! I wonder if it really works p2p. It should if it is using IPFS to distribute the file.
I don't remember if I ever told you I want to code a PoC where I use a local server to stream a file to p2p (as a torrent) yet in reality my local file is an open stream (node allows you to open files as streams) where I am adding chunks of data constantly from any source. I've seen this work using torrent-stream but for files, I'd like to do it for live sources (such as video input).
The AR Video Dapp needs live p2p to work.
|
|
||
| - Apps that use collaborative editing on shared data/documents. | ||
| - Apps that create & post or find & share content with other users. | ||
| - Apps that share disk space usage and that can benefit from P2P redistribution of content. |
There was a problem hiding this comment.
Rather than saying at the end, "btw, some of those ideas were similar to what we already did—see if you can go back and figure out which ones," I think it probably makes sense to say this alongside each Dapp's description. Maybe at the end or something, in italics if you want so that it doesn't look like it's part of the main description, you can say "btw, this is similar to our existing work on Thicket. Feel free to fork Thicket and start building!"
There was a problem hiding this comment.
I'm not sure how to do this. I like the idea but I can't find a simple way to add such reference. I already feel the text is too much and not sure I can fit this in:
-
Decentralised file collaboration and file sharing app with offline functionality. Bring in the best features of file sharing & collaboration tools out there and mix them with distributed technologies while working directly from the user's file system:
- Select folders to upload and set access rights to them and/or to individual files.
- Allow real-time collaboration on docs.
- Include new files simply by copying them to one of the selected folders.
- Work offline and merge the updates when reconnected.
- Access files when needed. The network allows to access files even if the author's computer is turned off.
- Keep files under version control; allowing users to merge updates or to branch out.
Where would the data be physically stored? Every node connected to the network would store and redistribute every piece of information. Only the original uploader holds the key to decrypt their own data, so only they can access it.
[apps that use collaborative editing on shared data/documents]
There was a problem hiding this comment.
Maybe the above way works, but do you think it will help the user while reading the text while it will only make sense of it till they get to the end?
There was a problem hiding this comment.
Oh, you're picturing it being some sort of label/link? I was just thinking we'd say the same thing over and over.
_This idea is similar to what we already build with Thicket. If you want to make this idea happen, consider using Thicket as a starting point.
There was a problem hiding this comment.
Hmmm, I don't like that at all. And if you think about it, it is like adding a label. But I'll keep the idea running in the background to see if I come up with some way to refer to it.
At one point I even thought of linking to each idea but that proved to change a lot of the structure:
Apps that use collaborative editing on shared data/documents: 1,4,5,6 // <- these are anchors
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
2 times, most recently
from
d46f583 to
db7324b
Compare
|
@chadoh all but the last suggestion addressed, can I get approval and if I come up with a way to tag/label the Dapps I'll add it (besides I still need to get approval for bits this can help in getting that process started) |
AquiGorka
changed the title
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
2 times, most recently
from
4a65fa6 to
6f35d02
Compare
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
4 times, most recently
from
4da11e6 to
9168601
Compare
|
|
||
| For some of us, trying to picture the future is a daily activity; some days this can lead into ideas that should not be pursued and other days can help guide the present toward a more desired future. Citrusbyte is a thought-leader in both software engineering and design, and as part of our work we commit ourselves to research experiments with cutting edge technologies. | ||
|
|
||
| This past September, my team at Citrusbyte embarked on a research project into decentralised applications. We set our goal to build a decentralised clone of Vine—the GIF sharing app. We started out from scratch, coding small, step-by-step sized features one at a time. We refactored once the new concepts where settling in our minds and came up with new concepts of our own. |
There was a problem hiding this comment.
where settling in → were settling in
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
4 times, most recently
from
38d3809 to
4e97309
Compare
AquiGorka
force-pushed
the
post/6-months-into-the-future
branch
from
4e97309 to
88bea3c
Compare
|
|
||
| ## Next steps | ||
|
|
||
| There is a big trend going on of [_X but with Blockchain_](https://angel.co/blockchains) and [_simply add Bitcoin to your business name_](https://www.nytimes.com/2017/12/21/technology/bitcoin-blockchain-stock-market.html) type of ideas. Does this mean the world is ready for a decentralised Internet? I don't think so. The hype might mean people are looking and working in the right direction, still I invite you all to dive into the [IPFS paper](https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf) to fully understand all the concepts behind such tools and protocols–we really enjoyed working out the details and grasping the required concepts to make our Dapp work. I am certain as more people read the document and get their hands dirty working with these technologies, the tipping point will be reached and Dapps will go mainstream. |
There was a problem hiding this comment.
Questions & suggestions on part of this:
The hype might mean [, however, that] people [clarify: what people? developers? investors? consumers?] are looking [what does it mean to be looking in the right direction? a better word might convey your idea better] and working in the right direction, [BUT, ... end this thought, saying something like "but the current Dapp ecosystem still has many gaps."]
stillTo get your footing, I invite you all to dive into the [IPFS paper]
There was a problem hiding this comment.
All-in-all, this paragraph reads much better than it did before. I like it!
|
|
||
|  | ||
|
|
||
| We also identified categories of Dapps that can be worked upon and that could start out from a fork of the work we did. These categories include:. |
There was a problem hiding this comment.
You have a :. there; remove the .
Also, consider adding a link to Thicket here, if Thicket is open source by the time we publish this. (And if it's not, this whole section is a little awkward!)
There was a problem hiding this comment.
True. I'll update once we publish Thicket.
chadoh
left a comment
chadoh
left a comment
There was a problem hiding this comment.
I like it in this form.
Something that you mentioned a while ago that we sort of lost sight of: making this an article about "you don't need blockchain to make a distributed app." We could make this article about that without too much modification, I think—just some extra stuff in the intro & conclusion, or maybe a slightly reworked intro/conclusion. If you think that sounds cool, then I think it might make the post even stronger and encourage you to go for it.
Whether you do that or not, at this point I think it's in good enough shape to submit it to Bits. I'm looking forward to getting more CBers' input on this! Thanks for all the work you put into this!
| - Apps that create & post or find & share content with other users. | ||
| - Apps that share disk space usage and that can benefit from P2P redistribution of content. | ||
|
|
||
| Let us know what other distributed Dapp ideas come to mind. We came up with this list after working with the technology and after we understood its inner ticks. We know these protocols & tools will help with problems that haven't yet been discovered. |
There was a problem hiding this comment.
I don't think "problems that haven't yet been discovered" is a strong way to end. It sounds like the "hammer in search of a nail" fallacy, to me. Like, "now we have this cool new tool, there's gotta be some problem out there that we can solve!"
I think this ending statement might be strongest if we end it after the first sentence. "Let us know what other distributed Dapp app ideas come to mind."
There was a problem hiding this comment.
I removed the ending line, I liked your suggestion.
That is true! Jajaja, but at this point I rather submit this to Bits and maybe work that idea inot another blog post–maybe one of its own. Again, thanks for all the help! |
2 participants
No description provided.