Add browser support to Reticulum/Nomad Network

[hardBSDk]

There's a plan for Reticulum/Nomad websites?

If the answer is yes, are you planning Chromium/Firefox support as proxy/extension?

[markqvist]

There is a plan :) But I am hesitant to move it forward until we are sure that we are sticking with the micron markup language, and what form it ends up taking, since it will be a bit of work to implement the micron->html parser/renderer and related stuff.

Currently there is also an open question on whether nomadnet pages should support "input fields" like HTML. This may seem like a silly thing to think too much about, but if you start looking into it a little more deeply, it opens up a pandoras box the size of the Boötes Void. I need like three days to stare into the air and think about it, but so far I haven't gotten around to that ;)

[hardBSDk]

That feature would be wonderful as it open window to alternative local Internet websites to compete with ISP + censorship resistant without IP.

[judahsotomayor]

I think Pandora's box is an apt description.
I like what the project Gemini FAQ says

"Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol. "

If Reticulum is serious about privacy, we need to be very very careful about what features we adopt from the existing internet.
Reticulum will not replace existing protocols. Rather than attempting to replicate them, I think it is better to focus on privacy, community/individual empowerment, and simplicity.
Of course, this doesn't mean we should fully replicate Gemini either. But if Reticulum as a project is to maintain its focus on low-bandwidth networks we will not be able to go far beyond plaintext.

[buhalo1]

Perhaps it is worth considering some elements of the WAP 2.0 protocol? There are quite a lot of interesting solutions both for the presentation of content and for its delivery through narrowband channels.

[4c3e]

@buhalo1 mind sharing some links for this protocol?

Also, just want to point out that the latest version of micron includes text inputs and forms! Of course micron pages could try and use these inputs for malicious reasons, but assuming reticulum browsers do not make unauthorized requests (this is an area of modern web browsers that is currently awful), I do not see how they can currently be used for fingerprinting or any other invasive practices against user's consent.

It is important to note that the only information leaked to the server in the current RNS Link API is hop count (this can and probably should be randomized slightly or removed, to help preserve some metadata), initiator anonymity is preserved by default.

[buhalo1]

Specs https://technical.openmobilealliance.org/Affiliates/WAP.html
Open source gateway https://www.kannel.org/overview.shtml

[4c3e]

Hey all, just wanted to comment here because I’ve done a bit of work towards this goal. In my opinion the best path forward here is to contribute to Agregore Browser, which is a chromium fork that adds the ability to easily add arbitrary protocol support to the browser’s Fetch API.

Relevant Agregore Github issue: AgregoreWeb/agregore-browser#180

The roadmap would most likely follow something like this:

• Finalize RRTP spec. This is something I’ve put on the back burner for quite a while, apologies, but I think generally we’re close to getting the first experimental version of the spec finished.
• Create a patched version of rnsd with a protocol similar to I2P SAM, this will allow the browser to send data to a local port that the RNS daemon is listening on, and will relay to whatever RNS transports are configured.
• Create a javascript RNS library to easily communicate with this local port over this simple protocol.
• Using this library, implement an RNS Fetch library. An easy comparison for how this will look would be the Gemini-fetch library.

Now Agregore doesn’t support the micron format, so eventually it would probably be best to have a micron->html converter as Mark mentioned previously, however, Agregore already support a gemtext render engine, and also a markdown render engine. Both of these options are text-only (the markdown engine might support inline images which might be a minor issue for low bandwidth comms) and should be good enough for users until a proper micron render engine is built.

Agregore is a great choice for this because they’re ideologically aligned with similar interests as RNS. And the project has already completed the hard job of opening up the browser’s fetch api to support arbitrary protocols. As a bonus, Agregore already supports http, ipfs, hypercore, and Gemini. Agregore also has a suite of web archiving tools built in, to allow users to easily turn https websites into archives, that can then be re-hosted on RNS or any of the previously mentioned protocols.

One thing that’s also important is that Agregore will hopefully get additional p2p-specific browser extensions that will make it more useable. One feature we have been discussing is a multi-protocol address book system which will essentially be a local file on your OS that holds a mapping between human-readable names to cryptographic identifiers for content or in this case RNS nodes. Because of the p2p nature of the browser, it’ll be easily accessible for users to exchange personal address books between each other, allowing content indexes to organically propagate without the need of a centralized indexing service. All of these additional features will just add utility for browsing RNS sites in Agregore.

Overall I’m super excited thinking about this integration and am hoping to continue working towards this over the next couple months. Happy to answer any questions about this :)

[4c3e]

beyond working on Agregore, I'm fairly confident a web extension could at least proxy certain tabs through a local socket like the i2p firefox extension: https://addons.mozilla.org/en-US/firefox/addon/i2p-in-private-browsing/

[hardBSDk]

What about HTML, HTML5, JS, CSS support with Reticulum websites?

[4c3e]

@hardBSDk hey sorry for the delay, was afk for a bit.

The really nice thing about the work the Agregore folks did with their custom protocol handlers, is that you simply need to build a Fetch API implementation that works with arbitrary data, then the browser logic will automatically use that fetch api in a number of places, this means that you could serve HTML5 websites with javascript or css source code that is loaded via a reticulum link (at least it is my understanding that this is possible).

The other really exciting behavior this enables is the ability to mix and match p2p in the same html document. So you could have a hypertext document where all the images are loaded by an "online" protocol like http or ipfs, but the html document itself can be served as a reticulum resource. This means if the internet were to go down, the document could still be retrieved, but without the heavy images, which would only work when connection to the "traditional internet" was online.

[ducksandgoats]

agregore is awesome, i contributed to it before and i'm in their matrix/discord room. i try to be active when my day job gives me free time. i also forked it and put my own changes on it. Hybrid Browser is my fork. it has handlers for p2p networks. and it also uses tor/i2p/lokinet/ouinet by using a socks/http proxy for them.

Hey all, just wanted to comment here because I’ve done a bit of work towards this goal. In my opinion the best path forward here is to contribute to Agregore Browser, which is a chromium fork that adds the ability to easily add arbitrary protocol support to the browser’s Fetch API.

Relevant Agregore Github issue: AgregoreWeb/agregore-browser#180

The roadmap would most likely follow something like this:

• Finalize RRTP spec. This is something I’ve put on the back burner for quite a while, apologies, but I think generally we’re close to getting the first experimental version of the spec finished.
• Create a patched version of rnsd with a protocol similar to I2P SAM, this will allow the browser to send data to a local port that the RNS daemon is listening on, and will relay to whatever RNS transports are configured.
• Create a javascript RNS library to easily communicate with this local port over this simple protocol.
• Using this library, implement an RNS Fetch library. An easy comparison for how this will look would be the Gemini-fetch library.

Now Agregore doesn’t support the micron format, so eventually it would probably be best to have a micron->html converter as Mark mentioned previously, however, Agregore already support a gemtext render engine, and also a markdown render engine. Both of these options are text-only (the markdown engine might support inline images which might be a minor issue for low bandwidth comms) and should be good enough for users until a proper micron render engine is built.

Agregore is a great choice for this because they’re ideologically aligned with similar interests as RNS. And the project has already completed the hard job of opening up the browser’s fetch api to support arbitrary protocols. As a bonus, Agregore already supports http, ipfs, hypercore, and Gemini. Agregore also has a suite of web archiving tools built in, to allow users to easily turn https websites into archives, that can then be re-hosted on RNS or any of the previously mentioned protocols.

One thing that’s also important is that Agregore will hopefully get additional p2p-specific browser extensions that will make it more useable. One feature we have been discussing is a multi-protocol address book system which will essentially be a local file on your OS that holds a mapping between human-readable names to cryptographic identifiers for content or in this case RNS nodes. Because of the p2p nature of the browser, it’ll be easily accessible for users to exchange personal address books between each other, allowing content indexes to organically propagate without the need of a centralized indexing service. All of these additional features will just add utility for browsing RNS sites in Agregore.

Overall I’m super excited thinking about this integration and am hoping to continue working towards this over the next couple months. Happy to answer any questions about this :)

sounds like this would work exactly the same way with how agregore's protocol handler's work. we would create a protocol handler that would interact with bittorrent/ipfs/hypercore/others, in this case it would be the javascript RNS library.

this is the bittorent-fetch package i worked on. rangermauve(creator of agregore) made their own. but there were changes i wanted to make, so i made my own. also made other handlers, for example one that interacts with i2p using a http proxy.

https://github.com/ducksandgoats/list-fetch
https://github.com/ducksandgoats/garlic-fetch

if this javascript RNS library can be made then it would be very doable to make a protocol handler for reticulum/RNS. this is really exciting, i have been busy with my day job, but i wanted to catch up on this. during the time i was working on this stuff, i became interested in how we can move data without ip. things like creating bluetooth/wifi-direct and similar things that would exchange data between devices, have like an offline network which in the end does the same thing as the ip stuff(as in moves data around) but without the ip stack. but this is even better, this would give the ability to merge multiple networks together, weather they are non-ip or ip. while reading about reticulum, i saw the radio and esp32 stuff. really fascinating. i will be watching and trying to find a way to see how i can contribute to this with great interest. just need to read up and learn in more details. can't wait until we can add this to p2p browsers. i haven't used python in awhile but this is a good reason to starting using python again for me.