HelloZeroNet/ZeroNet

Browser plugin for 127.0.0.1:43110 -less site access

Closed this issue Β· 45 comments

Possibilities:

Something you can do now: add 127.0.0.1 zero to your host file, start zeronet with zeronet.py --ui_port 80 then you can access zeronet sites http://zero/talk.zeronetwork.bit

Probably the browser plugin is the best solution (if possible)

+1
this would be really useful.
I checked Chrome extension API, they don't support listening for custom protocol.

.bit chrome extension using this: https://developer.chrome.com/extensions/proxy

if zero:// not possible then i think accessing sites http://1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr or http://1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr.zero also fine.

http://*.zero sounds good

.bit domains can be problematic that way: a domain could have clearnet ip address and also zeronet address representation.
So currently if you enter zeronetwork.bit with the .bit chrome extension installed it leads you to the github page, but in zeronet it should lead to 1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr.
Maybe it can be solved by prefer zeronet or prefer clearnet option.

how about? http://zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr

I just finished initial implementation https://github.com/goldenratio/zeronet-protocol-crx

But I have a problem :)
I am able to proxy to my xampp server, example: http://zero/xampp
but for ZeroNet http://zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr it goes ZeroNet's page not found page.

I am running ZeroNet from headless computer. I haven't tested it on localhost.

[18:05:47] Ui.UiServer 192.168.1.71 - - [2015-04-18 18:05:47] "GET http://zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr HTTP/1.1" 404 381 0.012192

Wow nice!
I think 1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr.zero is better because its looks more like a normal web address and if you enter zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr in chrome (without http://) it takes you to google search. 1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr.zero handled as normal url

ya, agree http://*.zero is better

I am trying to understand why I can't access http://zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr with the current implementation.

Under --debug flag I see,
"GET http://zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr HTTP/1.1" 404

but it seems ZeroNet doesn't expect http://zero in that request.
Not sure how to get rid of it .

I think if you can change it to *.zero then it will be good. currently zero/ is detected as part of request_path, if it has a . in it then it will be the domain.

it seems chrome automatically converts uppercase letters to lowercase in URL. duh! :)

for example:
1GamESVFyJfkmbxtcrLR2VX4m4VFmwyeRY.zero
gets converted
1gamesvfyjfkmbxtcrlr2vx4m4vfmwyery.zero

btw just noticed,

if you enter zero/1EU1tbG9oC1A8jz2ouVwGZyQ5asrNsE4Vr in chrome (without http://) it takes you to google search.

it doesn't take me to google search actually. It works as expected.

In my browser: http://i.imgur.com/Yl0ETg4.png (i have installed the extension)

yeah the lower-casing is a major problem and i think no easy way (if even possible) to fix it :(

maybe its possible with combination with omni-box plugins witch is receives all input you enter to address bar, but its hack-ish.

According to this: https://github.com/swalkinshaw/rs-ssh google lets you use custom protocol prefix, but you need a registered program for that (we can do that easily with zeronet client).

This protocols have to be case-sensitive because there is also a bitcoin:// protcol.

So it looks harder than I first throught...

It required some changes in the core request handling, but i got the chrome plugin working. There is still some problems with site links that needs more work.

I think its better to stick with .bit domains instead of .zero, later it allows us to support other dns providers. (.eth, .p2p, etc.)

nice!

added .bit to TLD list

also made 127.0.0.1:43110 to go through proxy, if ZeroNet is running on remote machine. Useful for current links out there on the internet (reddit)

Downloaded and updated to latest version of the plugin, everything working fine (/zero/* and direct .bit access), i'm going to do some more testing then i will release a version that compatible with it.

probably it would be smart to change the .bit to something zeronet related to prevent mixing with real namecoin .bit mappings, ideas that came up:

  • Change .bit to .zero. Example: http://talk.zeronetwork.zero Problem: It doesnt allows integrating other dns providers (like ethereum) and there is already an application for .zero tld
  • Change it to .0 or 0net. Example: http://talk.zeronetwork.0net Problem: Its hard to read (is that an O or 0?), Similar as .zero, but without icann tld problem
  • Change it to .zeronet. Example: http://talk.zeronetwork.zeronet. Problem: Similar as .zero, but without icann tld problem
  • Change it to .zerobit. Example: http://talk.zeronetwork.zerobit. It allows later add .zeroeth .zerobazaar or .zerop2p
  • zero:// protocol handler. Example: zero://talk.zeronetwork.bit. Problem: Chrome doesnt allows easily to do that, need registry hacking. Most forums doesn't converts it to clickable urls.
  • Keep .bit, but redirect non-existent domains back to chrome (not sure if its possible)

I'm liking the change to ".zerobit" if needed, but the more I think about it, the more I'm a fan of somehow using the protocol layer - zero://. This would have yet another benefit - we could resolve using TXT records in traditional DNS. zero://smokingcode.com could do a lookup in DNS for an TXT with a name/value pair for "zero" on smokingcode.com. .bit would remain .bit and use namecoin d/zeronet entries...
Maybe I'm just thinking too hard here.... But there's gotta be a way to configure a protocol handler, and even have a config to tell it a proxy zeronet to use if desired.

Currently the extension supports both .zero and .bit TLDs, but it is easier to support more.

Regarding zero:// protocol, Chrome passes it operating system level. We can listen to it by installing ZeroNet application, similar to what Skype does for Skype:// protocol. But I not sure how to go back to browser when zero:// protocol is detected. Probably for this reason "project maelstrom" forked Chromium to support custom protocols.

But I would stick with http://zero/site_name
Less hassel. But zero:// protocol should be preffered, but would require some work.. Probably fork Chromium.

Redirecting on 127.0.0.1:43110 request to /zero/[site] and http://site.bit would be better because localstorage (and cookie on multiuser) is domain-specific.
But exluding /uimedia/ because it holds the internal css and js files of zeronet and it will not avalible from http://www.site.bit/uimedia.

And i think it would be more usefull if pressing the extension button leads to the ZeroHello homepage and moving the proxy settings to extension options.

ya, right. Done

It works pretty good, I think you could submit it to google app store to make the install easier.

Nice, I had to restart chrome after removed the unpacked extension, but its working now

.bit + prefer (clear|zero)net sounds like the best option.

Perhaps we could use Navigator.registerProtocolHandler()? Then, if the server is sent a zero: or zero:// parameter, it just has to parse it and redirect to the final website.

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

you can only register web+zero://, but it's not really a good solution, because it's redirect back to 127.0.0.1:43110, so if you want to copy the link then you have to edit it manually again.

I am working on some improvements to @goldenratio's plugin and I noticed that several pages, including the welcome page are no longer rendering fully with the plugin when the http://zero/ or http://*.bit/ proxies are used.

I also have an idea about getting http://<hash>.zero to work. Since the hostname is lowercase, a bitmap can be used to prefix the lowercase hash which marks the characters which should be capitalized. It could look something like this: http://<hexBitmap>-<hash>.zero/. I would like to update the plugin so that all pages are redirected to a .zero or a .bit.

Ultimately, I think using the zero:// scheme with a custom browser is the best. I think an Electron app allows for custom schemes. The Brave browser is built on Electron. A custom browser for ZeroNet would be awesome!

I agree with @dmp1ce , I think using the zero:// scheme with a custom browser is the best too,

Since ZeroNet is written in Python. We can use cefpython to make a browser.

@HelloZeroNet, I think it is already implemented.

I cannot find a working implementation. The chrome extension has been removed.

Right now the plugin does not works correctly due an error in chrome. (sideffect of newly added site isolation)
I already reported to the developers, they accepted the issue and seems like working on it.

@HelloZeroNet
Do you have news about it?

There are a few related issues about URL scheme and handler (#83, #266, #1295).


I think that the best scheme would be zero:// (or zeronet://). This scheme is also the most valid according to URL syntax:

URI = scheme:[//authority]path[?query][#fragment]
authority = [userinfo@]host[:port]

In this case, zero:// would be the URL scheme. This would correctly separate ZeroNet sites from classic websites and ensure there are no conflicts.


There are some with other suggestions:

  • Suggestion for using custom domains (http://talk.zeronetwork.zero, http://talk.zeronetwork.0net ...) is too complicated. It also doesn't allow other DNS providers. It is also not so valid URL syntax.

  • Usage of http://zero/site-address is also not good. It doesn't look so good and it also means different things. According to URL syntax, there is domain zero which contains subdirectory site-address. This is not so valid and would also not prevent CORS.


I recommend that you make browser extension (for Firefox and Chrome) that would handle zero:// scheme, offer some developer tools and managing ZeroNet. Maybe it could also bundle ZeroNet directly into it. I will maybe create this extension in the future if I will have time.

If this is not possible, I recommend that you make custom browser for this. And I strongly recommend to not use Electron/Chromium for this because it has some problems. Electron uses a lot of memory and it doesn't have great performance. And Chromium is controlled by Google and it is not good for any decentralized and privacy projects.

It would be better to create a custom build of Firefox (or Tor Browser) which would contain bundled ZeroNet and extension for managing it. Problem with this is that it will require experience with Firefox codebase so it could be hard.

See rllola/ZeronetBrowser#87 for some more details.

The main problem I have with zero:// is that 1.) It's used for the trackers and 2.) When you visit a zite in ZeroNet, you are NOT using the ZeroNet protocol - you are using a local HTTP server that serves the files that are stored locally on your computer. The ZeroNet protocol is what handles storing those files locally. They're separate things.
Additionally, what if we wanted to add more servers to the ZeroNet client. Me and @imachug have created a Gopher plugin for ZeroNet that will serve these local files/zites to a gopher client. The gopher client uses gopher://. It's the same thing. The ZeroNet protocol handles storing the files locally, then we overlay a local server on top of that to actually serve the files based on the protocol we want to use, by default it's HTTP, but we can also use Gopher, FTP, etc.

The zero domain would just be localhost. And yes, there is a subdirectory containing the site-address - that's what the data folder is.

I don't understand how http://talk.zeronetwork.zero isn't valid URL syntax... it looks valid to me.

The zero domain would just be localhost. And yes, there is a subdirectory containing the site-address - that's what the data folder is.

This wouldn't prevent CORS. And ZeroNet sites should be on separate domains (even if there are on the same server).
And what's then the point of using http://zero instead of localhost:43110?

I don't understand how http://talk.zeronetwork.zero isn't valid URL syntax... it looks valid to me.

Sorry, I was editing my comment before I published it and I forgot to change this.
It is valid (except that Amazon applied for .zero TLD).
But the problem with it is that it doesn't allow other DNS providers. Some solution to this may be to use http://talk.zeronetwork.bit.zero or something like this.


I didn't know about that additional Gopher and FTP plugins. Now I probably agree that zero:// scheme is not so good.

I would now recommend to use http://talk.zeronetwork.bit.zero or something like that. This would allow accessing sites without (address.zero) and with (domain.bit.zero) domain. It would also allow other DNS (like ENS or even classic DNS) and also other protocols (Gopher, FTP...).

Update: Better to use .zeronet, because .zero is registered for Amazon. Other stays the same. And if you have some time, maybe even apply .zeronet to ICANN.

@DaniellMesquita Did you just link from this issue to this very issue?

@DaniellMesquita Did you just link from this issue to this very issue?

Wrong English, although I understand what you mean.
I'm not advertising this issue in every issue. But that is really related.
Use dat-like lowcase addresses, and will be less hard to develop a browser protocol integration.

You parsed it wrong, not me. "Just" is used here as "right now", and "this very" means "this issue, not anything else" (google the meaning of "very" as an adjective). So, I said that you linked this issue to itself.

You're correct @imachug ! Your English isn't wrong.