sammacbeth / dat-fox Goto Github PK

I've hear that from Firefox 57 there would have support for extensions with decentralized protocols (really enabling dat:// protocol and others).
I think this extension should update to this.

When datfox Add-on will be available on mobile?

This extension replaces window.URL with its own constructor and thus makes its static methods unavailable (URL.createObjectURL() and URL.revokeObjectURL()). I haven't looked into fixing it yet but it should be trivial.

The DAT protocol moved to the HYPER protocol. Do you plan to fix this extension for the new protocol? Cheers!

Hi @sammacbeth

I have being pursuing an effort of implementing experimental WebExtensions APIs so that dat, ipfs, ssb and other dweb protocols could be implemented and add-ed to firefox via add-ons. Here is the repository for this project https://github.com/mozilla/libdweb

I am also looking trying to get community behind this effort. Right now feedback from authors like yourself would be invaluable. Right now theres'n not much to try other than Protocol Handler API, but it's also a think that likely can utilized by dat-fox to provide native dat:// urls and a good test case to asses if combination of protocol handler + native messaging would enable a better experience.

If you are able and interested to try this out that would be amazing & I'm happy to assist in any way I can.

Thanks!

1. open http://ee172d7cd9235b2cf86ea9481e8a40e48cea29c743036621edc79a4765aa0281/ in Firefox

Front page stops at Dec 4th.

1. open dat://ee172d7cd9235b2cf86ea9481e8a40e48cea29c743036621edc79a4765aa0281/ in Beaker

Front page updates through Dec 22

Allow archive versions to be specified in urls (e.g. with +version).

For example, give the option to automatically redirect from

https://beakerbrowser.com/

To your Dat website

dat: //beakerbrowser.com/

I’m running Firefox 69.0 (64-bit) with an up-to-date version of the Add-on. When visiting my app on localhost:3000 I’m getting the error message window.DatArchive.load is not a function. (I tried running the app on a different port, didn’t change anything.)

The window.DatArchive exists and some of my functionality worked until I got to the page that uses the .load method. I should note that the app runs properly in the Beaker browser.

The setup page says everything is working fine:

    Checking helper connection

    Successfully started dat gateway at localhost:3016.
    Helper version 0.1.0 up-to-date

I even tried setting the Dat gateway Address to localhost:3016 since 3000 seems to be the default.

Visiting or trying to do a cURL on this port returns the message: TypeError: Cannot read property 'replace' of null

Let me know if there’s any other information I could provide.

1. Load a normal webpage over HTTPS (no CORS or nonsense).

2. Attempt to load an image resource over Dat on that page

Image newer loads. Browsers says “waiting for dat://” indefinitely.

The mage loads instantly if the Dat URI is opened directly in the top frame.

A number of web servers return 200 OK when they mean to return 404 Not Found. These end up producing error pages like this:

Error: Invalid .well-known/dat record, must provide a dat://{key} url

This test should probably check to see if a Dat URI is provided in the returned file or not and only return an error if the Dat URI is malformed.

Result of stat or readdir with the stat option should contain isDirectory and isFile functions. Currently these do not survive serialisation and not available in the page script. Can be reproduced on dat://editor-cryptic.hashbase.io/

When I click the "View local files" button on a dat archive, it tries to send me here:

moz-extension://8b706831-cd2b-4f70-adb2-0ba06120c502/home/[my user name]/.local/datfox/library/[name of archive]

And in the browser I get the following message:

File not found

Firefox can’t find the file at moz-extension://8b706831-cd2b-4f70-adb2-0ba06120c502/home/[my user name]/.local/datfox/library/[name of archive]

Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.

If I navigate to /home/[my user name]/.local/datfox/library/[name of archive] in my filesystem, I can find the files okay, but the actual link seems to be broken.

Thanks for your work on this!

Make the api to the helper also available over http so that gateways can be hosted in other environments (e.g. public gateway). This is also a prerequisite for Android support.

Firefox Quantum 58.0.1 (64-bit) on Debian/Linux

We're missing a way to manage the library Dats

https://i.imgur.com/I0uycOA.png

the registry key is supposed to modify/add does not exist at all.

When using the Home Assistant project (https://www.home-assistant.io/) with this plugin enabled in the latest version of Firefox (63.0) I am unable to navigate between sections. The HASS UI is built with Ploymer I believe and whilst all the links in the navigation look fine in the inspector (e.g. /states), when navigating the URL is updated to /statesundefined. This makes it impossible to use unfortunately.

For now, with dat-fox disabled, all works well again.

It's a widely known security vulnerability and is a horrible idea. Also doesn't help when the script fails and you need to debug it.

Just.... don't do it. At all. Ever.

Getting errors like:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at dat://ed8fd80fbbfb4396fdb1445f449563a52bcce1e3d10b48515a1ec784442dfb61/activity/factory.json. (Reason: CORS request not http).[Learn More]

when trying to read contents from a dat other than the origin.

This is when trying to run dat://federated-wiki-client.hashbase.io/ with dat-fox in the current developer edition of Firefox.

I notice later that the readdir calls are all returning a rejected promise with "Error: Another hypercore is stored here". A connected issue? deleting the problem archive from the datfox cache resolved the "Error: Another hypercore is stored here" error.

Currently it forks directly with no prompt.

When DatArchive.fork is called with incorrect arguments the dialog still appears, but in a broken state. We should just reject immediately.

Reproduction:
The self-mutating site example calls DatArchive.fork with a DatArchive as the first argument (this is perhaps an older version of the API). This may be a case we should handle for backwards compatibility, but it demonstrates this issue at present.

In a index.html scripts loaded from a dat url fail to load. For example

<script src='dat://federated-wiki-client.hashbase.io/client.js' type='text/javascript'></script>

fails to load with Loading failed for the <script> with source “dat://federated-wiki-client.hashbase.io/client.js”. in the browser console.

1. Load a normal webpage over HTTPS (no CORS or nonsense).

2. Attempt to load any resource in a sub-frame over Dat on that page

   <iframe src="dat://beakerbrowser.com/img/what-is-beaker.svg"></iframe>

The top frame is unexpectedly redirected to the sub-frame’s address; replacing the entire document with the contents of the iframe. This makes is difficult for use cases like peer-to-peer embedded videos.

Potentially a security vulnerability as any iframe can replace any document they’re loaded in. Unknown impact.

From sammacbeth/dat-fox-helper#6

We can put some information on the setup page to instruct users to reset any existing configuration for dat URLs. This could be added to https://github.com/sammacbeth/dat-fox/blob/master/addon/pages/setup.html

When loading a dat site which has HSTS, we can get a conflict between the browser, which tries to prevent a insecure load on this domain, and this extension, which tries to downgrade the connection in order to proxy over dat. This leads to an infinite redirect.

One possible solution would be to detect the browsers https upgrade redirect, then fallback to the raw dat url for this site.

Please instead of using dat.redirect use a Reserved domain. In the unlikely case that something goes wrong with the extension, nobody could every register .redirect. For example dat.redirect.localhost would work.

what is dat:// and why should I care?

Hello,

Today I tried out the 0.2.0 version of the extension, downloaded from github, as it is more recent than the one on the Firefox Add-ons Store. The previous version did not work either, but didn't give any indication as to why.

With this extension, however, when I open the setup page and attempt to check the helper connexion, this error occures :

Checking helper connection
Attempting to start gateway... TypeError: resetBridge is not a function

I installed the dat-fox-helper from github, with the script provided in the README, that I read and understood before executing it.

I'm running a Debian 9, with Firefox 60.3.0esr (64-bit).

Thanks for your work, I hope you can fix this issue soon.

General information

Domain: localhost:3000
Browser: Firefox 62
OS: Void Linux

Scenario

1. Start a SPA application (for example using React)
2. Save a file via the front-end application
3. Open a file saver popup
4. File is saved
   => OK
5. Enable dat-fox extensions
6. Save a file via the front-end application

Expected Result

The browser tries to save a file by showing the pop-up to save a file

Actual Result

Saving the file gives an error URL.createObjectURL is not a function (we are using FileSaver.js and that library is throwing that error) and doesn't open the file saver popup.

Extra information

I noticed that this is only a problem when developing locally on the application, when we create a production build and push to our development instance on AWS we don't have this issue.
Is the extension overriding browser globals? Is there any weird behavior you can think of using localhost?

If you need any more information, I'll try to provide it for you.

Hi,
I really like where this extension was going and was wondering if you'd be interested in some discussion about how to go about enabling the DatArchive API.

I was thinking that it could be done by having a gateway which produces replication streams for dats.

What it could look like is this:

• Set up a WS server
• When getting an incoming connection, get the Dat public key from the URL
• Create a memory-only instance of the archive and pipe the WS socket to the replication stream
• Do the usual peer discovery dance
• Client-side use node-dat-archive with a patched discovery-swarm which only identifies one peer, the gateway.

This will simplify accessing new Dats, but does not provide a mechanism for creating and seeding new ones.

It keeps on loading. Manjaro Gnome + Firefox 66.0.1 (64-bit) + https://addons.mozilla.org/en-US/firefox/addon/dat-p2p-protocol/