Hey all, I'm the author of this project. Happy to answer questions or talk about the software.
It took about 2 months to write. I used yo-yo[1] for the frontend UI, which I enjoyed using a lot. The rest is standard es6 and electron.
Dat & IPFS are the first two protocols to get integrations. I also know Maidsafe has been considering using Beaker as well. I might integrate SSB [2] next, because of my history with that project.
> Beaker is built on Electron, which is a temporary solution. Electron breaks Chromium's process-level sandbox, which needs to be restored. Electron also has API limitations, which (for instance) keeps Beaker from injecting new Web APIs into iframes and workers. So, in the near future, we'll need to fork Electron.
Can you explain how the process-level sandbox is broken using webviews?
Also, I hope y'all don't have to fork Electron but instead can upstream your changes. I have successfully implemented web APIs that use private IPC to communicate w/ the backend side (and then killed node integration). Granted I have not attempted this with iframes and web workers...I wonder if it's just an oversight on their part and would welcome a PR. I know the webview and custom protocol support leaves a lot to be desired. But I fear all of these Electron forks (e.g. Brave) for browser use will end up fragmenting features that could help all browser implementers.
On a side note, this is really awesome. I have not dug into it too deeply, but as I have mentioned before here and on the maidsafe forums, this is a big step towards removing user tracking while leaving JS functionality intact. Simply removing the "server" or mutable calls of the implemented protocol (or at least making them opt-in) prevents the fingerprinting from being "phoned home". I hope this project succeeds.
> Can you explain how the process-level sandbox is broken using webviews?
Sure thing. It's the node integration that's an issue. To let the render processes import node's APIs, the process-level sandbox had to be removed. Whether node-integration is enabled or not, that process-level sandbox is gone. The javascript sandbox is still present, but the os-enforced sandbox is gone.
This situation isn't totally unsafe, but it's not as safe as it can be. The process-level sandbox acts as a strong second-line of defense against API compromises. For a project that doesn't need node integration in the browser (such as Beaker) then it'd be best to re-add it.
> I hope y'all don't have to fork Electron but instead can upstream your changes.
That would be nice! The team that works on Electron is superb, but they've explicitly stated, in conversations with the Brave team, that they're not interested in supporting Browser projects such as Brave or Beaker.[1] Their position is reasonable - though obviously I'd prefer they changed it. I'll stay in touch with them, and do my best to contribute upstream when it makes sense. If I don't have to fork, in the end, I certainly won't.
Please consider integrating into an existing browser with userbase instead of making your own. This is the only way IMO to get IPFS used by real people. I mean to make sense publishing content in IPFS in the first place.
The two candidates I'd suggest are Firefox (obvious) and Vivaldi. The latter has already reached stable release stage and desperately needs a feature to set itself apart from other Chromium forks. It's only partly open-source now but the team have plans to go full in future.
SSB looks very exciting. If all of these are supported by Beaker then would it make sense to cross link from SSB to IPFS to support something like video hosting?
Props to you guys for making the P2P web more accessible.
@pfraze: This browser is a great idea! I'm getting more and more into decentralized web stuff, and this browser is exactly the kind of thing for decentra-newbies like me to keep diving in! Kudos!
[decentra-newbie or decentra-newb: a term i just now coined to refer to newcomers or novices utilizing decentralized digital technologies. ;-) ]
Also - off-topic - but I just checked out the patchwork project, and wow, very cool! I'm in the midst of running an internal/family-only experiment running my own matrix.org server...but when i have a free chance, will definitely check out patchwork.
I was really just the frontend guy for Patchwork. Much more credit goes to Dominic Tarr [1] for building the underlying tech, and I should also mention Cel [2] and Mix [3] for their work there. Hopefully we'll have Patchwork running in Beaker soon. More about it: https://scuttlebot.io/
I have a lot of interest in Matrix as well. The work looks very solid, and it could make for a good infrastructure solution for push notifications, webrtc signalling, and chat in general.
that's pretty much it. You store a copy of your world of content out to 2 degrees of connection. Messages are gossiped along lines of trust (friendship)... technically it doesn't even need the internet, just computers periodically bumping into each other and gossiping
This introduced me to IPFS. I was already aware of Matrix, which had a lot of very cool work done on it, which very much sold it to many of us as "what XMPP should have been." Although XMPP is still a very viable protocol...
OTOH, I've heard a lot of dodgy things about Etherium, particularly from the currency side, and just the security in general.
IPFS is exciting, looking very much like Freenet from a publishing perspective, but without making anybody who want to see that data download a very cumbersome program (and the security, of course). The history system is also interesting. However, the single client and server implementation concerns me. Especially because it's written in Go. I don't make judgements about code quality by language (plenty of good programmers hack in Node and other JS environments), but if we're going to use this thing as the distributed platform of the future, it had better be cross-platform. And Go has a... Less than exellent track record for being easily ported (I won't go so far as to say that Golang Is Trash, but that post alone speaks volumes about the porting experience, and there have been plenty of others). Plenty of organizations run on BSD, Solaris, Illumos, or another Unix. If the future is coming, I'd rather they be part of it, and even if Go runs for them, I'd rather not make it any harder on then than necessary.
Sorry. I clearly didn't do my research well enough.
But so many of these systems have only one implementation, and no spec. Matrix, Dat, and IPFS are all ahead of the game on that, even though Matrix has only one server implementation, AFAICT, and all the Dat tooling I've found is in node. It's better than Scuttlebot, in any case.
> And Go has a... Less than exellent track record for being easily ported
I'm not sure what you are talking about with this, but I thought Go had great cross platform support. Can you point me to a resource documenting your "Less than excellent track record"?
"Golang is Trash" (http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/) is now the classic bashing of Go's implementation, it doesn't talk about issues encountered porting it, which is what I was talking about. The post I referred to in particular was the one by 4ad, who did the solaris port of Go, on this very site (https://news.ycombinator.com/item?id=8817568). However, as I reread it, it becomes clear that the problems it discusses may have been fixed. Nonetheless, Go is a product of Plan 9, and as such, its implementation is... interesting.
The worst horror story is that Go encodes the syscall table on most platforms, which can cause problems on platforms like Solaris, where the syscall table isn't guaranteed to remain the same over time. However, that code's been written, so Go may be better off than I thought.
In general, however, the more implementations, the better. So I maintain that we should build more implementations of the IPFS and dat protocols (they're apparently fairly similar). Because if we're building the next web, it cannot be linked to a single platform, especially if that platform is node, the only platform that all these new protocols seem to have bindings for.
How are you shipping IPFS with your electron app? I was under the impression only the GO implementation of IPFS is complete. Are you simply running IPFS Go as another process? (And where is it being included? I couldn't find it in the code base)
Basically you have three different ways of using IPFS in JavaScript today.
1. Use js-ipfs which is a implementation of IPFS in javascript. This requires that you either have both frontend and backend being ipfs nodes, or at least in the backend, otherwise content added won't be seeded since you close your browser when you're done.
2. Use js-ipfs-api and go-ipfs together. Start a daemon with go-ipfs and then point js-ipfs-api to it. The daemon will essentially act like one of your backends.
3. Use js-ipfsd-ctl that kind of is the same as number 2 but starts a go-ipfs node for you, and then returns an instance of js-ipfs-api, already pointed to the daemon.
The author in this case went for 3. Probably the reasoning is that js-ipfs and go-ipfs can't really talk to each other yet, and go-ipfs has the bigger network and is more popular.
There isnt a doc available yet, but there are two key properties. The first is, you can create mutable IPFS archives by generating a keypair; the pubkey becomes the identifier, and new versions are signed by the private key.
The second property is, you can use DNS TXT records to provide shortnames that map to the pubkey (or, I believe, to a static hash-id also). Run 'dig txt ipfs.io' to see an example.
And it works really great! I've been serving my personal web page for months now at /ipns/pablo.rauzy.name :).
The only catch is that you need to republish regularly (I do it using cron two times a day) otherwise the IPNS do not work after some time, but I'm not sure it still is the case.
You put the human readable part underneath the hash, like `/ipfs/QmPJnEf5933cXteZmaMJkphCW1CtpcMMVx7N6rUr8cZAok/jquery/3.0.0/jquery.js`. In this case, the hash represents a directory of everything from CDNJS and the `jquery/3.0.0/jquery.js` part is a file in that directory. For added readability, there's a thin layer of mutability called IPNS that can map a domain name to a hash, so you could point `cdnjs.com` to `QmPJnEf5933cXteZmaMJkphCW1CtpcMMVx7N6rUr8cZAok` and not have to remember that long ugly hash.
Same here; this decentralized and distributed internet stuff is exciting. I agree the ipfs addresses are a bit long and kinda illegible...I once thought that maybe there could be future self-hosted (quick-n-easy-to-roll-out) url shorteners, but then figured these would be ephemeral at best, which might sort of undo the content-address-ability of the ipfs content...and then my brain began to hurt, so finished my beer, and went back to chilling. ;-)
It took about 2 months to write. I used yo-yo[1] for the frontend UI, which I enjoyed using a lot. The rest is standard es6 and electron.
Dat & IPFS are the first two protocols to get integrations. I also know Maidsafe has been considering using Beaker as well. I might integrate SSB [2] next, because of my history with that project.
Cheers.
1. https://www.npmjs.com/package/yo-yo
2. https://scuttlebot.io/more/protocols/secure-scuttlebutt.html