dat://72671c5004d3b956791b6ffca7f05025d62309feaf99cde04c6f434189694291/
Nobody follows me yet though...
PS: I think this would pick up more steam if you changed the title to "Decentralized Twitter clone with Beaker and Dat Project"
Here is my feed: dat://73bf68c7e480d53f231d0f077e2865afa098d0b6b1bd3eb65364b9b7cb149d0c
edit, a quote from @neauoire:
>>> Good morning, I will fix up the client now. Make sure it catches the timeouts, and also make @ names clickeable by everyone.
nice!
mine: dat://1d09fb13964569d6d03b90c9c2944f3f34bc5aebd1e5a02d3a259b347789c982/
How is Dat different than IPFS?
IPFS and Dat share a number of underlying similarities but address different problems. Both deduplicate content-addressed pieces of data and have a mechanism for searching for peers who have a specific piece of data. Both have implementations which work in modern Web browsers, as well as command line tools.
The two systems also have a number of differences. Dat keeps a secure version log of changes to a dataset over time which allows Dat to act as a version control tool. The type of Merkle tree used by Dat lets peers compare which pieces of a specific version of a dataset they each have and efficiently exchange the deltas to complete a full sync. It is not possible to synchronize or version a dataset in this way in IPFS without implementing such functionality yourself, as IPFS provides a CDN and/or filesystem interface but not a synchronization mechanism.
Dat has also prioritized efficiency and speed for the most basic use cases, especially when sharing large datasets. Dat does not make a duplicate of the data on the filesystem, unlike IPFS in which storage is duplicated upon import. Dat's pieces can also be easily decoupled for implementing lower-level object stores. See hypercore and hyperdb for more information.
In order for IPFS to provide guarantees about interoperability, IPFS applications must use only the IPFS network stack. In contrast, Dat is only an application protocol and is agnostic to which network protocols (transports and naming systems) are used.
You could prob swap this question for "what is the difference between DAT and Bit Torrent" since ZeroNet also uses BT and DAT is similar tech... but this has been answered already.
Outside of this, DAT is agnostic and modular while ZeroNet is focused on p2p website. So a comparison of ZN and Beaker (rather than DAT) would make more sense since both have same focus. Beaker's approach is to use a web browser wrapper (electron/chrome) while ZN is headless and allows you to use your existing web browsers. Beaker is able to offer more/different features because of the tight relationship with a browser app and this affords a powerful path forward beyond just serving static files as web pages. However, ZN also lets you leverage browser database and ability to make simple webapps.
It's really just different approaches to accomplish more or less the same goal of a p2p web. You could say Beaker is more cutting edge because it uses newer DAT (something new) and open to integrating IPFS etc vs being bound to BitTorrent (older tech).
The nice thing is, you can run ZeroNet and Beaker at same time and enjoy both p2p web networks ;-)
I think that things like p2p transport via Tor, bt, etc. are all red herrings. The robust computing infrastructure for the next-gen, distributed information system that the world needs, should not be tied to transport layer concerns like that. It should work reasonably well via flash-drive-sneakernet as it does over fiber and LTE.
Also, how secure is beaker? Are there any security audits?
There is even a third element which is missed by this false dichotomy, which is that "blanket anonymity" is not the same as "managing how much of my identity I want to reveal".
Without the latter, you actually end up with a digital commons whose social dynamics asymptotically approach the chans or Youtube comments.
Also, is it really necessary to git clone the rotonde repository? Why not go to a starter Dat url and use Beaker to fork your own copy?
Any POC project is going to start out with a highly manual install process.
During setup, you git-clone the application code and put it into a dat site you create. The app code publishes by modifying files within its own dat. When you visit somebody's profile, you're actually visiting a new site, so there's no uniform software layer on the social network. A lot like indie Web software.
There's a new 'application' pattern we're working on for the upcoming 0.8 release. In that pattern, the app dat and the data dat will be separated. This wont replace self-mutating sites, but it has some benefits as an alternative: apps will be able to update independently of the data, the browser will provide install and signin flows, and apps can provide persistent UIs.
There's a lot of other ideas we're kicking around (intents) and some kind of out there experiments (the app scheme [1]) so we'll need lots of feedback, esp from folks like @neauoire. Pre-release of 0.8 should happen by the new year.
1. https://github.com/beakerbrowser/beaker/wiki/App-Scheme
EDIT: updated for clarity EDIT EDIT: and brevity
Why not make profiles something modular that can be easily published and shared online, but also in a 'mesh network' setting where you publish and receive from devices within your general vicinity.
The profile should be a bundle of data about the individual, published by the individual. More of a standard than a service. There could be 3rd-party services to scrape and store what pepople publish. There could be 3rd-party services to produce nice cookie-cutter profiles, like resume templates. Services for hosting, collating, searching, viewing profiles. And people could have loads of different profiles for different parts of their lives, and separate them as much or little as they feel like. But at the core of things, the profile would belong to the User.
I was able to build a 'Slack clone' as a one-day hack, using Hypercore + Electron: https://github.com/lachenmayer/p2p-slack-clone-poc
I think we'll be seeing a lot of these kind of projects soon :)
The reason I ask is that me, Mafintosh, Juan at IPFS, Dominic with Scuttlebutt, Feross at WebTorrent, Substack, and others all met back in 2014 for our different P2P projects. All of us had slightly different approaches. Juan and others seemed mostly interested in hash addressing, which I think is great but doesn't solve the end problem of data sync. Seems like Dat deals with that fairly well, but not for highly mutable data (versus large scientific files). Meanwhile we ( https://github.com/amark/gun ) tackled that problem first, because it seems like CRDTs are the most relevant for killing traditional centralized Facebook/Twitter/Reddit/gDocs like apps, and hashing is more applicable for killing centralized YouTube/imgur like apps. Both are necessary, but it certainly seems harder/easier based on which underlying P2P tools you use.
You are one of the few people actually jumping in and building end apps (thanks for sharing your chat app!), and we need more people doing that (not just all of us who are trying to rebuild the underlying architecture). So I would be curious to hear your experience comparing the different use cases behind dat/IPFS/gun/WebTorrent/etc. it would make for an interesting and informative comparison article. Thoughts?
In time, I think that a lot of backend plumbing around DAT and dex web stuff will not necessarily be JS, and if there are native mobile apps (if Google and App allow for them), those will be written in those native languages. But the front-end is almost certainly going to JS and modern web stack.
Just make sure the protocol doesn't depend on weirdness from JS land to allow other clients in and you're good to go.
The developers do plan to support Windows, but there are some missing dependencies that need to be built first.
If so, which one is winning?
I don't think you can decide "who is winning" right now. They both are still in development and both have strengths and weaknesses resulting from different development focus that do not have to remain as they are.
> No, it’s a fork of the Chrome browser.
https://beakerbrowser.com/docs/inside-beaker/faq.html#is-bea...
edit: my bad, there's also markdown support.
It also needs to have a wasm backed canvas.
Also is there any chance of switching to Janea Systems' NodeJS builds so that we get 32-bit and x86 Android support?
http://www.janeasystems.com/blog/announcing-node-js-mobile-a...
[0] https://github.com/maidsafe/safe_browser [1] https://safenetwork.wiki/en/FAQ
