Storing .bit starting webpage as namespace entry

[virtual_master]

Supposing the value fields are increased to 5k.
What would be if the client would support browsing .bit domains with reading html code from the value field and giving over to the browser ?
In a client field for browsing you give in the bit domain and start - the browser opens with the start-page from the value field associated to that .bit domain.
It would be not much in 5k but enough for a welcome message and a couple of links or redirection.
Hosting .bit pages would be much easier because it can be redirected or linked to any sub-domain or deep link.

[snailbrain]

Supposing the value fields are increased to 5k.
What would be if the client would support browsing .bit domains with reading html code from the value field and giving over to the browser ?
In a client field for browsing you give in the bit domain and start - the browser opens with the start-page from the value field associated to that .bit domain.
It would be not much in 5k but enough for a welcome message and a couple of links or redirection.
Hosting .bit pages would be much easier because it can be redirected or linked to any sub-domain or deep link.

i thought about this too

[virtual_master]

Of course there would be some related risks also with the content but now can be also any content introduced.
If you have an open accessible database then any content can be introduced even if it is not connected with any browser.
And if the contesting system is also implemented then anybody can contest it(for a fee) if he/she doesn't like it.
This could eventually bring a higher acceptance for .bit domains.
If the website creator knows how to do it the the site can remain on the .bit domain and loading content in a frame from a dropbox account or other providers.
Eventually some templates could be available.
................
Other possibility would be restricting the content only for some templates, which can be customized.
The contents(inclusive the title) would be stored outside of the blockchain, only the frame type and the frame links are stored.
This would require very little space so even now with 0.5k would be possible to do it if the client would support it.

[biolizard89]

I was thinking about something similar: add an "http" field, which compliant implementations should display as an HTML iframe, an HTTP redirect, or otherwise load the HTTP URL specified by the value of the "http" field. The value would be used as a "base" URL; i.e. I could specify this:

name: d/myforum
value: { "http" : "http://www.mysite.com/forum"}

Visiting http://www.myforum.bit/1234 would take me to http://www.mysite.com/forum/1234

This scheme might need modification to handle multiple resolvers (e.g. the implementation should be able to choose a generic TLD, .onion TLD, .i2p TLD, etc. based on user choice), but I think that's easy enough.

I think this would meet the main use case of your proposal, without using as much storage in the blockchain, and would also prevent idiots from shoving Javascript malware in the blockchain or whatever other bad things might happen from embedding arbitrary web pages in the blockchain.

Another benefit of this way of doing it is that (I think, haven't tested) proxy-based implementations like Convergence should be able to transparently translate the HTTP headers such that the URL bar still works as normal; i.e. the browser thinks it's actually visiting the correct .bit page even if you click links, but the server receives the headers requesting a .com page.

[phelix]

I was thinking about something similar: add an "http" field, which compliant implementations should display as an HTML iframe, an HTTP redirect, or otherwise load the HTTP URL specified by the value of the "http" field. The value would be used as a "base" URL; i.e. I could specify this:

name: d/myforum
value: { "http" : "http://www.mysite.com/forum"}

Visiting http://www.myforum.bit/1234 would take me to http://www.mysite.com/forum/1234

This scheme might need modification to handle multiple resolvers (e.g. the implementation should be able to choose a generic TLD, .onion TLD, .i2p TLD, etc. based on user choice), but I think that's easy enough.

I think this would meet the main use case of your proposal, without using as much storage in the blockchain, and would also prevent idiots from shoving Javascript malware in the blockchain or whatever other bad things might happen from embedding arbitrary web pages in the blockchain.

Another benefit of this way of doing it is that (I think, haven't tested) proxy-based implementations like Convergence should be able to transparently translate the HTTP headers such that the URL bar still works as normal; i.e. the browser thinks it's actually visiting the correct .bit page even if you click links, but the server receives the headers requesting a .com page.

This is a great idea.

supersite.bit --> http://supersite.somefreewebspacehoster.com location bar: supersite.bit

supersite.bit/products --> http://supersite.somefreewebspacehoster.com/products location bar: supersite.bit/products

Cheap domain names with SSL and TLS for everybody!

[biolizard89]

I was thinking about something similar: add an "http" field, which compliant implementations should display as an HTML iframe, an HTTP redirect, or otherwise load the HTTP URL specified by the value of the "http" field. The value would be used as a "base" URL; i.e. I could specify this:

name: d/myforum
value: { "http" : "http://www.mysite.com/forum"}

Visiting http://www.myforum.bit/1234 would take me to http://www.mysite.com/forum/1234

This scheme might need modification to handle multiple resolvers (e.g. the implementation should be able to choose a generic TLD, .onion TLD, .i2p TLD, etc. based on user choice), but I think that's easy enough.

I think this would meet the main use case of your proposal, without using as much storage in the blockchain, and would also prevent idiots from shoving Javascript malware in the blockchain or whatever other bad things might happen from embedding arbitrary web pages in the blockchain.

Another benefit of this way of doing it is that (I think, haven't tested) proxy-based implementations like Convergence should be able to transparently translate the HTTP headers such that the URL bar still works as normal; i.e. the browser thinks it's actually visiting the correct .bit page even if you click links, but the server receives the headers requesting a .com page.

This is a great idea.

supersite.bit --> http://supersite.somefreewebspacehoster.com location bar: supersite.bit

supersite.bit/products --> http://supersite.somefreewebspacehoster.com/products location bar: supersite.bit/products

Cheap domain names with SSL and TLS for everybody!

I'll see if I can put together a more formal draft spec for this feature soon.

[virtual_master]

This is a great idea.

supersite.bit --> http://supersite.somefreewebspacehoster.com location bar: supersite.bit

supersite.bit/products --> http://supersite.somefreewebspacehoster.com/products location bar: supersite.bit/products

Cheap domain names with SSL and TLS for everybody!

Yeh. This could revolutionary. Not only cheap and decentralized domain names but combined with cheap and decentralized content hosting. You don't need any more a hosting provider which has an IP where you can point on it with your domain.

I'll see if I can put together a more formal draft spec for this feature soon.

Thanks.

Their is a general problem with frames/iframes which appear sometimes: multiple framing of the same content if you click on the home link of the starting page.
- The negative visual effect could be avoided if the basic page have no content at all and the iframe takes all the page. Then even by multiple framing no difference can be seen.
- I am not sure what special optical and behavioral effects could be produced in this particular case of of browsing .bit domains and coming to multiple inline frames. I guess it depends also on the implementation method.
- Another issue is when you link to another .bit domain.
a. If the .bit resolver is started from the Namecoin client it wouldn't work at all.
b. If the .bit resolver is as a browser plugin(which on request of a .bit domain is working together with namecoind) then it works.
But: startdomain.bit - framed(linkeddomain.bit -> framed(content))
So you are surfing linkeddomain.bit but you still see above startdomain.bit.

Even if some of this problems appear it is worth to implement it and this effects can be avoided if the website uses proper programming.(linked .bit domains should go in a new window or tab)

[gigabytecoin]

Unless every single machine trying to access .bit has a full copy of the NMC blockchain, this would be unfeasible.

root DNS only serves up ip addresses in exchange for domain names, there is no way to have a DNS return web content.

[biolizard89]

Unless every single machine trying to access .bit has a full copy of the NMC blockchain, this would be unfeasible.

root DNS only serves up ip addresses in exchange for domain names, there is no way to have a DNS return web content.

(1) The same could be said about Tor/I2P/Freenet resolution. (2) You can return a TXT field which includes such things. And more importantly, (3) why would you be using Namecoin if you don't have namecoind? If you're using a 3rd-party DNS server instead of namecoind, you're now less secure and private than using your ISP's DNS. It is possible to make a lite client which can return provably secure results without downloading the whole blockchain history; this will probably be worked on after the libcoin rebase.

[phelix]

I was thinking about something similar: add an "http" field, which compliant implementations should display as an HTML iframe, an HTTP redirect, or otherwise load the HTTP URL specified by the value of the "http" field. The value would be used as a "base" URL; i.e. I could specify this:

name: d/myforum
value: { "http" : "http://www.mysite.com/forum"}

Visiting http://www.myforum.bit/1234 would take me to http://www.mysite.com/forum/1234

This scheme might need modification to handle multiple resolvers (e.g. the implementation should be able to choose a generic TLD, .onion TLD, .i2p TLD, etc. based on user choice), but I think that's easy enough.

I think this would meet the main use case of your proposal, without using as much storage in the blockchain, and would also prevent idiots from shoving Javascript malware in the blockchain or whatever other bad things might happen from embedding arbitrary web pages in the blockchain.

Another benefit of this way of doing it is that (I think, haven't tested) proxy-based implementations like Convergence should be able to transparently translate the HTTP headers such that the URL bar still works as normal; i.e. the browser thinks it's actually visiting the correct .bit page even if you click links, but the server receives the headers requesting a .com page.

This is a great idea.

supersite.bit --> http://supersite.somefreewebspacehoster.com location bar: supersite.bit

supersite.bit/products --> http://supersite.somefreewebspacehoster.com/products location bar: supersite.bit/products

Cheap domain names with SSL and TLS for everybody!

I have a feeling we are getting a little closer to this with FreeSpeechMe (new Convergence Firefox plugin).