local GUI controlling local retroshare backend

[Calvin]

I'm now trying to set up pyrs to talk to the existing RetroShare instance on the same machine using ssh/rpc. I'm hoping that the current pyrs from git is still compatible with the latest release of RetroShare 0.5.5c, does anyone know?

Also, I'm a bit confused with the setup. I'm using the instructions at the wiki page "Documentation:retroshare-nogui", and it describes four steps:
1. Copy the .retroshare directory - this isn't required because RetroShare is already installed here
2. Create an ssh keypair without password - OK. I understand it doesn't need a password because it's just using the keys to make the connection. If I've got the key, I don't need a password to connect. OK.
3. Create a password hash by running "RetroShare-nogui -G". What is this? I don't want to enter yet another password so I leave it blank, just as in step 2, but then it just returns to the prompt without apparently creating anything.

It sounds like I need to enter (any) password into this, to generate a hash, and this hash is then given back to RetroShare-nogui in step 4. But I don't get the point - it doesn't sound like I give this password or its hash to pyrs, so what's it for? I thought if I had the ssh keypair from step 2 then that's enough for pyrs to communicate with RetroShare-nogui without any other password, right? Pyrs just needs to know my RetroShare password I think?

[cave]

@javars
if you want to help developing, good idea is to contact cyril directly and join the chatroom. there is the most information and discussion available. and also v06 forums are quite more used compared to this webforum here.


hi calvin,

i would not use PYRS too much. it was the very first started web thing from RetroShare team. and was dropped prior to DJRS. DJRS was dropped too... both rely on RPC, which is not available in v06 anymore.. AFIAK.
PYRS relys on RPC interface, which seems also to be not used in v0.6 anymore. pyrs is not futureproof atm.
better idea is to contact electron to work on v0.6 RS-Social plugin and develop in this direction.

If there was a basic Web interface to change the friendlist and do some basic settings for no-gui, i would be very happy. i miss this feature for years!

best regards

[Calvin]

i would not use PYRS too much. it was the very first started web thing from RetroShare team. and was dropped prior to DJRS. DJRS was dropped too... both rely on RPC, which is not available in v06 anymore.. AFIAK.
PYRS relys on RPC interface, which seems also to be not used in v0.6 anymore. pyrs is not futureproof atm.

Oh dear. I thought pyrs was going to be the way to go if it was a stable interface. electron led me to believe it would be continued:

Just one more question - is your intention to remove the current ssh-rpc interface, or will the new json-http interface be an additional way of controlling the backend? I assume the existing guis still need to be supported.

The current ssh-rpc and the new rpc interface can live besides each other. There are still a few issues, for example chat messages will only be delivered to one interface (This is also why ssh-rpc is only available for nogui). But these issues are solveable.

That made me think that pyrs (and other existing things like retroflux) would continue to work as-is. From what you just wrote, that's a wrong assumption of mine?

If the current way of working is going to be discontinued, do the pyrs devs and the retroflux devs know about this? Are you working together on how to bring them over to the new way?

If in the future, the only interface will be http/json, then I have another question: if I take the current 0.6 sources from sourceforge's svn, will I get a working version of this http/json interface already with which to try things out? Or is it not that far ahead yet? For the things which are currently working, do they have a fixed interface already or are things still likely to change, perhaps drastically, before it goes out into a real release (whether that's 0.6 or maybe later)?

[cave]

I'll tell electron and cyril to answer here in detail, i don't want to cause more confusion if i am not 100% informed.

HowTo Contact: -> http://retroshare.sourceforge.net/team.html

[electron]

Hi Calvin, here are clear words about what will happen and what not:

first the bad news:
- nobody is working on ssh-rpc. I think it does not compile in current trunk. Maybe someone fixes it. Maybe not. I will not put more work into ssh-rpc. Yes i'm not happy about this, i have build things on top of it myself. But i think i can build something better and something more easy to use.
- i'm not yet in contact with retroflux. I wanted to, but it did not happen. Thanks for the reminder.
- DJRS is from drbob. He is either away or i give him other bugs to fix. I don't expect he will continue DJRS. Sad but true.
then the good news:
- a JSON over http interface is currently being developed by me. I also work on a new webinterface. I plan to continue this work. Code is here: https://gitorious.org/rssocialnet/rssocialnet (for trunk/v0.6 only)
- the JSON over http interface is not stable. I change whatever i like whenever i like. This is because i'm not absolutely sure what i'm doing. I try things and if they are good they stay. Else i remove them. If someone takes the time to try and give feedback, i would be happy. Unfortunately the docs are not ready, i only have a small test which could be used to generate docs.
- expect progress to be slow, but there will be progress.
- until now my plan with JSON, http and reactJS works. I'm very happy about everything. I think it is good to only need JavaScript/HTML/CSS on the client side. And nicely (de)coupled with the server side which is just C++. Installation and configuration consists only of copying the plugin and some files (currently you have to compile yourself, but this will change).

Below is what i posted to the internal forums in v0.6.

From time to time it pops up that rs-nogui is not usable (Re: Bug: RS06 Modes not saving after exit).

Or said positively: rs-nogui has much room for improvements and has great potential.

The defects are obvious:
- missing features
- ssh-rpc is to complicated to set it up correctly

I want rs-nogui work like this:
Install and start rs-nogui with ssh or a graphical managment tool. This stuff is part of the OS.
The command line to start rs-nogui should be as simple as possible.
example:
$ retroshare-nogui --webinterface 8080
Now RS provides a webinterface on port 8080. It allows to manage keys and locations and to log in.

Further control and usage would happen through the webinterface. Either directly or by tunneling the webinterface through a RS Plugin. The second idea would solve all NAT, DNS and encryption/authentication issues.

Steps towards this goal:
- make new plan for webinterface: done
- implement new webinterface backend: half done in rssocialnet plugin
- implement http server in rs-nogui, i want to use libmicrohttpd
- make the html, css, JavaScript (with react.js)

What will happen with ssh-rpc?
I don't want to maintain the protobuf stuff. I think my JSON stuff is better. If someone gives me valid reasons why protobuf is superior and JSON is shit i will talk about this. For now JSON works and is two times less complex.
In the new JSON over http interface in rssocialnet, JSON is just an encoding. It can replaced for something else at any time. In contrast, the old protobuf stuff is tightly coupled to protobuf. With a table string identifier->integer, it would even be possibel to transform JSON to somethign similar space efficient as protobuf. But i think we don't have to care about space efficiency at this point. The real bandwidth consumers are images, audio and video streams.
Maybe we want to keep SSH to transport JSON messages. The ssh server would be there, it just needs a few lines of glue code to connect it to the JSON interface.

Chatserver
It would be nice to use the same rs-nogui for normal operation and the chatserver.
We could use a lua script to manage the friends list, or we can use php and the JSON over http interface to add and remove friends.
But this is the future. Currently there is no need to replace existing and working chatserver code.

[Calvin]

Hi guys, and thanks for your replies.

nobody is working on ssh-rpc. I think it does not compile in current trunk. Maybe someone fixes it. Maybe not. I will not put more work into ssh-rpc.

OK, that's good to know. Then I'll forget about that route.

- a JSON over http interface is currently being developed by me. I also work on a new webinterface. I plan to continue this work. Code is here: https://gitorious.org/rssocialnet/rssocialnet (for trunk/v0.6 only)

That sounds very good. I was a bit confused about rssocialnet though, this is a plugin to add social aspects on top of retroshare, right? So to me that sounds quite independent of any json/http interface work. You could have social features without the interface, and you could have the interface without the social features. But it sounds like you're developing both parts together, am I right?

- until now my plan with JSON, http and reactJS works. I'm very happy about everything. I think it is good to only need JavaScript/HTML/CSS on the client side. And nicely (de)coupled with the server side which is just C++.

That sounds very encouraging. I'm sure you hate questions about timescales, but do you plan to deliver the first parts of this with 0.6, or later? Have you any idea when that might be? Even for just the basics working?

[electron]

I was a bit confused about rssocialnet though, this is a plugin to add social aspects on top of retroshare, right? So to me that sounds quite independent of any json/http interface work. You could have social features without the interface, and you could have the interface without the social features. But it sounds like you're developing both parts together, am I right?

Yes, social networking features and the new interface are independent. I'm developing them together, because an http server existed in rssocialnet. And all the RS plugin code was there, the repo was set up...

I'm sure you hate questions about timescales, but do you plan to deliver the first parts of this with 0.6, or later? Have you any idea when that might be? Even for just the basics working?

I don't mind if you ask about timescales. It is an important question. The problem is I don't know when I will code what. And when I play with new things like JavaScript, many unpredictable things happen. A problem with this interface is, that some parts are not so well machine-testable. I have to build a web interface at the same time, to see if it works. For example the search: an automated test would not have revealed doubled results, because I would not have tested this. I only saw it when I tried it by hand.

You better ask specific questions like "It is possible to get the list of friends?". Then I would say: yes. Or you tell me: "I want to send chat messages". Then I would see what I can do.

Basic things already work: I have a webinterface to display the friendslist and get it automatically updated when it changes. Add/remove friends should be possible, but it is untested. Same with downloads.