-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide multiple dat hosting/sharing on Bunsen #40
Comments
@chrisekelley At the moment it's tempting to go with some fork of dat-gateway because it supports multiple dat archives and @RangerMauve has been working on a new DatArchive library called dat-archive-web that gives you the DatArchive API with help from the gateway.
This PR solves all of those problems but does introduce a new problem not flushing dat archives that don't need to stick around thus filling up disk unnecessarily. However, it does not yet have a DatArchive API solution. |
I think With regards to same-origin issues, I'm panning on modifying dat-gateway to support subdomains with base32 encoded dat keys. For example loading
(the brakerbrowser.com dat url) could be done with
Once I have this working, you could set up a DNS wildcard that directs |
I like the base32 idea. It makes it easy going back and forth between dat archive address and base32 encoded dat archive address. No map required.
Agreed, there needs to be some kind of signal. Perhaps a subdomain like |
Would look something like...
|
They should be shorter since you have twice as much information per character. With regards to persisting data, I think that should be a Bunsen specific service and running on a separate port from the gateway. It should provide the credential tracking that Beaker would be providing as well as tagging archives to be persisted |
Yeah! Maybe fork off of my fork of dat-gateway and add the changes there. |
Ya I could see that being a thing. That would be like self discovery? LOL it works and I never thought about doing it. If you clone a dat, share it, go offline, then in another folder clone it... It finds itself being shared on your local computer.
I haven't had any luck, they always end up longer :-/ Here's another approach where you hit
|
@RangerMauve What direction are you thinking makes sense? Am I messing up the base32 and it actually comes in under 64 characters for a dat archive address or does the second approach, while a bit awkward, make sense? |
The problem is that the base32 library is converting between base32 and ASCII. You'll probably want to find something to convert a buffer to base32 and then use |
Riiiight. I vaguely remember wrangling with this on an IoT project. Will give it another go. In the meantime I opened up a PR to @pfrazee's dat-gateway to get the ball rolling upstream. pfrazee/dat-gateway#6 |
Moving this conversation partly over to the PR pfrazee/dat-gateway#6 (comment) |
@RangerMauve - I've forked your version of dat-gateway and we're now using its websocket-replication branch - I'm really excited about the possibilities you're opening up in enabling websocket support. dat-gateway is now in master and support of multiple dats is working.
I merged @rjsteinert 's PR enabling CORS support from here into my fork: pfrazee/dat-gateway#7 I'm going to close this issue now that we have multiple dat hosting enabled. |
@chrisekelley Thanks! One nit in the review then we can merge it in. :D I'm going to continue the work on DatArchiveWeb, but I think my roadmap looks like:
|
Right now, Bunsen is limited to hosting/sharing one dat at a time. How can we implement this support?
Here is the route that handles a dat submission and hosts it in Bunsen: https://github.com/bunsenbrowser/bunsen/blob/master/www/nodejs-project/index.js#L78
We're currently using the dat-node library to join the network/share the dat and mirror to download it to the fs.
The text was updated successfully, but these errors were encountered: