ricochet
ricochet copied to clipboard
ricochet-im
Please @special do something
Ricochet is used by many people, please, update the project. It's just a few hours of work. @special @s-rah
Yeah, ricochet really needs an update and you could make it so much better
-Recompiling with Qt 5.12 LTS. -Master branch, no need to review pull requests. -Update Tor to latest 0.3.x series.
I already did it locally, but I don't own this official repository.
would it be possible for you to fork Ricochet and update it like you did so others could download it?
would it be possible for you to fork Ricochet and update it like you did so others could download it?
OK, I will, check my fork in a few days.
Adding v3 onions will be hard for me (not a C developer) but not impossible.
People willing to help me develop and fix Ricochet do it on my fork:
Help me test this build on Linux: https://github.com/cypherbits/ricochet/releases/tag/v1.1.4.1
@cypherbits any chance of getting a windows build?? I saw you released a version on your fork
@mva1985 after days of trying to compile it to Windows I think I almost have it. There was a bug which is not fixed on main Ubuntu yet that made an error compiling Qt for Windows... I will make a Wiki entry on how I did it and I hopefully will publish the Windows port soon.
Not good, I'm still stuck trying to cross compile for Windows, not with compile errors on the OpenSSL front. I even tried to compile it on Windows with a bunch of errors too.
We need developers. I'm not a C developer.
Sorry to say I don't have much time right now to work on this and that I finally could not compile it. There are many developers out there, why no one wanna help me a little? :(
With some tweaks, I could cross-build ricochet for Windows on the current Debian sid with mingw64.
Could anybody tell me how to update git submodules under buildscripts/src/ (such as Tor)? I tried, but it's too confusing for me...
they only way I could help is by testing a windows build if you are successful
Hey @mhatta: I haven't tested this myself, but the command git submodule update --remote should work (in the root of buildscripts). If you need to change the URLs for some reason, they're stored in buildscripts/.gitmodule.
I'd just like to take a moment to note that an organisation I'm working with at the moment is gathering resources to bring Ricochet up to speed: see https://github.com/blueprint-freespeech/ricochet-refresh for more.
With some tweaks, I could cross-build ricochet for Windows on the current Debian sid with mingw64.
Could anybody tell me how to update git submodules under buildscripts/src/ (such as Tor)? I tried, but it's too confusing for me...
I tried to update submodules, Qt version too, but it broke... it is not detecting correct submodules or something... IDK There are some modules that do not exists in newer versions of Qt because they are integrated on main Qt.
PD: happy to see people contributing.
PD2: Please people, post how and where do you compile things.
So I've got a successful build with current Tor on Ubuntu 18.04 with the Linux buildscripts -- I'll look at Windows cross-building soon.
Seems I could produce Windows 64bit installer package w/ Qt 5.12.4 & Tor 0.3.5.8. Try it if you want:
https://github.com/mhatta/ricochet/releases/download/test/Ricochet.exe
I'll refine this later.
Hi @noneuclideangirl, currently I'm working on my own fork repos, but if you could add me, we can work together on blueprint-freespeech repos. How do you think?
Me too, I want to contribute, I know about QML/design part and can help compiling things.
@mhatta please, explain more how did you compile it for WIndows. Where and how.
Feel free to -- I don't have the ability to add you to the team but you're more than welcome to submit work!
@noneuclideangirl Well, then It doesn't make much sense to use your repo, so I'll stick to mine...
@cypherbits You may check my buildscripts repo: https://github.com/mhatta/buildscripts/
My Ricochet ID is (for now) ricochet:tn5bmeldy2w6ghgf , but most of the time I'm offline.
Building with mingw32 is really difficult and I couldn't succeed after all. Somehow 32bit/64bit confusion happens and the generated binary never works. Building with mingw64 is quite easy but there are still several pitfalls (posix / w32 incompatibility, localtime_r problem, etc.). Needs more work.
I think @s-rah 's cwtch is very promising. I'm willing to housekeep ricochet, but maybe new effort should go into cwtch. The problem is, I know C++, but I'm a Go illiterate...
Ok, I think this one is good enough: https://github.com/mhatta/ricochet/releases/tag/v1.4.1-revised1
I'm now consolidating the existing patches.
If everyone of us create our own repository and we don't have one main official repository, we will accomplish nothing.
Important: planning.
I think as we are just a few, we should want to maintain Ricochet, update Qt, some QML and Tor versions and include some fixes and GUI fixes/design. We can even try to include onion v3 support, that would be good, but, please, do not try to get any new big features, we are few people and there is an alternative to Ricochet already functional called Cwtch.im
That means we should maintain Ricochet + get fixes + get v3 onions = stable and SECURE Ricochet (as there won't be any new code to be vulnerable).
Cwtch is written in Golang so is memory safe by default, and includes hidden and zero-knowenledge servers to store messages when users are offline and more features coming soon. We should join that project and maintain Ricochet only until a good stable version of Cwtch is released.
I know this sounds really ugly but what about rewriting in nodeJS with a web front end? I'm not a fan of this myself but I have to admit, system compatibility is very good.
Also my id is ricochet:ricochetytijv2kh if someone is interested. (Yes, it has ricochet twice)
I know this sounds really ugly but what about rewriting in nodeJS with a web front end? I'm not a fan of this myself but I have to admit, system compatibility is very good.
Also my id is
ricochet:ricochetytijv2khif someone is interested. (Yes, it has ricochet twice)
Nope nope nope nope nope
A really bad idea. nodeJS is not that safe and consumes many system resources.
As I said, the new project Cwtch is already making new features Richochet does not have. It is implemented in Goland: memory safe but fast and cheap for systems.
Ricochet: maintenance mode. New features and development: Cwtch.
Do not start your own project, we want a good solution for users. I started TorTribe (you can see my Github) in Java, but I will close it and join Cwtch so together we can make Cwtch great for all people.
nodeJS is not that safe and consumes many system resources.
There are AFAIK no safety problems in the node engine itself. In fact, a JS implementation is probably safer then the original ricochet client considering JS doesn't suffers from attacks that target unmanaged languages.
The claim about it eating a lot of system resources is also a lie. In fact, my nodeJS test server application eats about 10 MB of memory, while ricochet uses over 40 when idling for a few hours.
Do not start your own project, we want a good solution for users.
That's one of the worst advice you can give to people. From a security point of view, software diversification is very important. Any security flaw found would be devastating if all people were to use the same program. An added benefit is that when someone wants to fork and make changes to a client, they can pick the language they understand best.
nodeJS is not that safe and consumes many system resources.
There are AFAIK no safety problems in the node engine itself. In fact, a JS implementation is probably safer then the original ricochet client considering JS doesn't suffers from attacks that target unmanaged languages.
The claim about it eating a lot of system resources is also a lie. In fact, my nodeJS test server application eats about 10 MB of memory, while ricochet uses over 40 when idling for a few hours.
Do not start your own project, we want a good solution for users.
That's one of the worst advice you can give to people. From a security point of view, software diversification is very important. Any security flaw found would be devastating if all people were to use the same program. An added benefit is that when someone wants to fork and make changes to a client, they can pick the language they understand best.
What I mean about that is that there is no benefit of redoing Ricochet with nodejs and we should focus on helping other project replacing Ricochet already in development. NodeJS on the GUI part is RAM hungry and the app executable is big too.
We CAN and SHOULD recompile Ricochet with the newest Qt and change some QML so the memory footprint is lower. Actually just updating Qt version should do the magic as QML engine improved a lot.
I am not saying not to do software diversification, but sometimes each people start doing the same thing in parallel from the start and they stop and get tired and accomplished just an unusable thing. If the efforts were together, they would have developed a good solution.
I mean there is a tiny line between diversity and fragmentation. If we start forking Ricochet and developing on our own, which version should end users download?