ZeroNet Protocol and Developing apps

[MarBlen79]

My question is regarding of the future of ZeroNet regarding better developer support.

Having an app and being able to remove the back-end using a tool like ZeroNet would be incredible useful for most of the apps out there.

But currently this idea doesn't seem possible. While it's great to be able to access different Zites when you run ZeroNet. Commercially speaking users/customer won't do all the work (Tor+ZeroNet+Zite url) to try a new website.

Are there any plans to make a lightweight ZeroNet that can be integrated and use in the background without the client knowing? Like IPFS does.

Is my believe that will make it more developer friendly and increase adoption.

[martinvahi]

I'm NOT a ZeroNet developer, but supposedly the Microsoft has literally ported Ubuntu Linux userspace to Windows 10. When I first heard about it, I thought that it must be some sort of an April fools joke, but as it turns out:

https://www.youtube.com/watch?v=PP_T_m0UV9E

https://docs.microsoft.com/en-us/windows/wsl/install-win10

Supposedly they did it to support Ruby, because Ruby developers, including me, have been ignoring the whole Windows platform very consistently. I haven't tried it myself. It might be crappy vaporware or yet another "Microsoft Silverlight" that will be dropped like the https://en.wikipedia.org/wiki/Windows_Services_for_UNIX and the https://en.wikipedia.org/wiki/IronRuby#License were dropped. However, I believe that "the masses" evaluate

comfort above all else

and since the core idea behind the ZeroNet is that there are locally stored copies of HTML_JS_CSS based LibreOffice/Microsoft_Word document analogues that can be updated by the person, who holds the private key to sign the updates(usually the author of the 1. version of the document), the ZeroNet does not really offer real-time communication the way the chat-room oriented

https://matrix.org/ https://about.riot.im/

offers. The ZeroNet is excellent for blogs and wikis, but I would not even try to do any layman-consumer grade things with it, because technologies that offer real-time communication offer more comfort features.

On Windows You may try to install things by using the https://chocolatey.org/

[HelloZeroNet]

I think for the file transfers it could be possible to create a websocket based, javascript client. The SQL database and storing/validating lots of files could be more problematic.

If someone up to writing a client like this I happy to offer bounty for this from the donations.

[purplesyringa]

There is ZeroNetJS by @mkg20001, @HelloZeroNet

[martinvahi]

Suppose someone frankensteins together the

https://webtorrent.io/ https://github.com/webtorrent/webtorrent

and the ZeroNet by creating a Zite that includes both, the ZeroNet standard JavaScript library/API and the WebTorrent JavaScript library, then there will be 2 network access points for the zite. One at the Python based server and the other directly from the browser through the WebTorrent library. I have NOT tried the combination, but at first glance I do not see any technical difficulties, why such a Frankestein might fail to work, except that

THE HISTORY OF SOFTWARE DEVELOPMENT

shows that not all software developers take their time to think things trough. The 2 network access points will probably start to introduce broken zites just like the C/C++ memory management introduces a lot of crashing software. I'm not saying that the C/C++ memory management is bad. In the past I have written speed optimized C++ for years as part of my main job, but I am saying that that level of carefulness is psychologically too high requirement for an "average", architecture design wise terribly sloppy, "web developer". Please, DO NOT EXPECT those people to TEST their WebTorrent dependent zites in a situation, where the WebTorrent library FAILS TO CONNECT TO THE INTERNET. Many of the zites by such "web developers" will probably have the state of their single page JavaScript application MESSED UP at such corner cases.

As of 2018_02 I believe that those, who really want to create the Frankenstein and who take their time to think calmly about the architecture of their zite, have that opportunity right now already. They can download the

https://github.com/webtorrent/webtorrent

and create their masterpiece, but I would refrain from adding that library to the ZeroNet standard JavaScript library, because if that demanding feature/tool gets into the "masses", then many "web developers" are NOT GOOD ENOUGH to use it even, if they have the knowledge, the technical skills for using it. It's a matter of psychology: some take their time and think calmly, others just smash whatever pile (of ...) together and "publish away"! It seems to me that in this regard the various graphics designers are THE WORST, because they see a site as a "picture", not as "software". With pictures the artists do not need to think about network traffic, dependencies, data sizes, algorithmic complexity, breaking of network connections, etc.

[martinvahi]

P.S. I'm NOT an author of the

https://webtorrent.io/ https://github.com/webtorrent/webtorrent

but a 10EUR bounty for a good tip would buy me ice-cream :-) Bank account details: http://intervaarium.softf1.com/lounge/requisites/en/

(I'm not saying that I have earned it. But, if, for some weird reason, somebody thinks that I've done something useful and there is some money to spend, then I'll accept the ice-cream wire transfers :-)

[mkg20001]

@martinvahi I have plans to add IPLD support to @ZeroNetJS which would allow bittorent integration easily

[MarBlen79]

I was looking into this a little bit more and below are some ideas or ways to use ZeroNet like it is right now.

Desktop applications: There are examples of using Electron (app GUI) and zerorpc to connect JS with Python. ZeroNet already provides ZeroFrame API so most of the job is done (zerorpc won't be needed). Making a desktop app with Electron requires to manually change the code of this branch (removing tray icon, default website, sites that come with ZeroNet). Creating a ZeroNet "core" should solve this part. With "core" I mean no kind of UI just like an API that can be started in a thread. Obviously, the current GUI can be added on top of the "core" version.

Mobile applications: It's difficult creating mobile apps with Python. Qt is an option. Kivy is also one option, but according to the issues in ZeroNet-Kivy repo the UI gets buggy. Maybe doing something similar to what I said before can help the integration with Kivy. The problem is that if someone wants to use ZeroNet they are tied to doing it in Kivy which is not good (according to reviews is a lot slower).

Apache Cordova/Ionic won't work, since they are just webviews. I didn't look into React Native but it could be an option. NativeScript lets you create native apps with Javascript, according to the documentation you can create threads and integrate C++ code to the app.

I am not sure if there is a way to easily go from Python to C. According to StackOverflow, Cython could be an option.

I also found transcrypt.org which seems it can help porting Python to JS.

I tried to integrate IPFS in an Apache Cordova app and it worked (including pub-sub). There are many websites built on top of IPFS because it's really easy to integrate it. I posted this issue to point out how much more developer friendly ZeroNet could be. Because as a developer, ZeroNet seems it could be easier and better to use when trying to create a P2P app.

[jacobbogers]

Ethereum blockchain will have distributed storage go online in a few including distributed messaging, they also plan to have services (http enabled contracts) run on their blockchain, its amazing but basicly it is merging a lot of the concepts with zero net into their blockchain

[martinvahi]

@MarBlen79

... Mobile applications: It's difficult creating mobile apps with Python. Qt is an option. Kivy is also one option, but ...

Given that a ZeroNet node is expected to re-distribute the pages that its user viewed, the ZeroNet mode should not run on any cellphone, because that would drain the battery and it's probably not that healthy either, for humans, to have a cell phone near by that runs an upload to some cell tower 24/7. That is to say, Mobile Apps that depend on ZeroNet should have some relatively stationary wired server to connect to and the Mobile App should be a viewing client of that, personal, server. Let's say, a Mobile App is paired with a ZeroNet node at person's home. The "meeting point" between the two can be some web software that is hosted at some cheap hosting service, may be

(~12€/year, Google Translate can probably translate Estonian for You) https://www.planet.ee/

or

https://www.veebimajutus.ee/ (~65€/year, I've been using their service for years for hosting my softf1.com, safest place that I know of for registering domains, Google Translate can probably translate Estonian for You.)

Some special software that runs at the same machine with the ZeroNet node, connects to the hosting service web application and the client at the cell phone also connects to the hosting service web application and the rest is just a matter of protocol. From that point onwards the Mobile App can be created in any technology that the Mobile App developer usually uses for creating his/her Mobile Apps.

That's just an idea. I won't be coding any of it anytime soon, except may be the mirroring web app at the web hosting site, because that's more universal than just the solution that I described in my current comment.

Thank You for reading my comment :-)

[danimesq]

I think for the file transfers it could be possible to create a websocket based, javascript client. The SQL database and storing/validating lots of files could be more problematic.

If someone up to writing a client like this I happy to offer bounty for this from the donations.

@mkg20001

@martinvahi I have plans to add IPLD support to @ZeroNetJS which would allow bittorent integration easily

How is the development of ZN-JS? I think you should accept the bounty from @HelloZeroNet @shortcutme

[filips123]

@MarBlen79 @DaniellMesquita @HelloZeroNet

I created ZeroFrame WebSocket API for JavaScript. It supports (almost) same features as default ZeroFrame that is included in ZeroNet sites, but it is using WebSocket client so it can be used in local programs, such as Node.js and Electron. It's not complete ZeroNet implementation in JavaScript, but just WebSocket client which connects to exiting ZeroNet instance.

This program is currently only available as GitHub Gist, but I will soon publish it to GitHub repository and NPM. I will also properly document it and add some more features.

What do you think? There are a few things I want to discuss before I will publish this as a package and create clients for other languages. They are available in Discussion sections of Gist.

I am also creating clients for Python and PHP, but I will wait before publishing to discuss all things that are related to them.

[danimesq]

Thanks, @filips123 Since 2017 I say ZeroNet needs to have its own desktop/mobile apps

[anoadragon453]

@filips123 Looks great. I did a similar thing for GDScript here but got burnt out on trying to abstract the commands into nice, game-friendly features.

Instead, focus on getting a connection to the ZeroNet daemon in every language working (and easy for people to install and get started) and then work on abstractions afterwards if you'd like.

Btw, are you interested in making a full ZN implementation in JS? I think it could really help ZeroNet adoption if one was out there.

[filips123]

Instead, focus on getting a connection to the ZeroNet daemon in every language working (and easy for people to install and get started) and then work on abstractions afterwards if you'd like.

Yes, I will try to support more languages (Python and PHP for start) with the same abstraction level as original ZeroFrame class.

There are still some things I want to discuss so please check them in Discussion section of Gist.

Btw, are you interested in making a full ZN implementation in JS? I think it could really help ZeroNet adoption if one was out there.

There are already some (mostly unmaintained) projects which tried to do this. See NPM for details.

[mkg20001]

There are already some (mostly unmaintained) projects which tried to do this. See NPM for details.

I, for my part, started https://github.com/ZeroNetJS, but later moved on. It could serve as a base, though it's a bit mixed up with my effort to port the zeronet protocol to libp2p for scalability. Happy to accept contributors that want to push it forward, some lower-level parts (like https://github.com/ZeroNetJS/zeronet-crypto) are really well written and already reusable.

[anoadragon453]

@mkg20001 Nice! Ok, I'll take a look when I have some time. Can I ask what the current state of the project is?

[filips123]

It could serve as a base, though it's a bit mixed up with my effort to port the zeronet protocol to libp2p for scalability.

Is it still compatible with the original Python client? If not, it should be. It's not good to have a slightly different version of the same thing for multiple languages, because they could be incompatible.

Also, regarding libp2p. Could it be used in original Python client as alternative protocol? @HelloZeroNet, what do you think?

[mkg20001]

@mkg20001 Nice! Ok, I'll take a look when I have some time. Can I ask what the current state of the project is?

@anoadragon453 Some parts are actually usable, like zeronet-crypto. The rest though... Good luck, there is stuff in there that I'd honestly throw out myself the second I'd rewrite it (partly already done that) It's heavily pull-stream based, but you could try porting it to async iterators for the sake of zeronet

If not, it should be. It's not good to have a slightly different version of the same thing for multiple languages, because they could be incompatible.

@filips123 Plan was full compatibility but also to have a seperate libp2p swarm for later integration of ZeroNet to IPLD and integration of IPFS/IPLD to ZeroNet. See https://github.com/MuxZeroNet/proposals/issues/2 for the initial idea.

The idea was to take the modularity of libp2p and toss it onto zeronet (for example you can simply add support for "libp2p-over-websockets" by just adding that websocket-transport module to the swarm, also DHT would be a feature and not only that but DHT could be swapped as needed like just another module, discovery is modular too (mdns with 1 line of code), etc)

[filips123]

@mkg20001 Would it be possible to also support that in Python?

There are many decentralized protocols. And more protocols ZeroNet support, more decentralized it would be. There just needs to be some mechanism to handle all of them.

[mkg20001]

@mkg20001 Would it be possible to also support that in Python?

https://github.com/libp2p/py-libp2p Python Libp2p is in progress

There just needs to be some mechanism to handle all of them.

Multistream tries to achive that. https://github.com/multiformats/multistream You should really check out the multistream docs & philosophy. Basically they try to make everything as easy to change as possible, so protocols can be replaced more easily. Just the tiny layer of multistream for protocol negotiation needs to be added on top. https://github.com/multiformats/multistream#the-protocol-path