Confusion between the two libresignal #28
Comments
|
To add to the confusion: |
|
oh bloody hell... okay, well, I added that to the list. |
|
@Zepmann wait, so option 3 is just the same build as this Github repo? Why should we note it as an alternative and just not say that this code is also on the experimental repo? |
|
I actually do not know for certain if it is the same build from this repository (@xmikos, can you clarify this?). If it is, the 'experimental' naming is still confusing, since the term 'experimental' is not used in this repository. |
|
Yes, it is. |
|
a) The apk in F-Droid archive repo is built from this Github repo. |
|
Alright, so there are basically two libresignal. Can we call one LibreSignal and the other SocketSignal or something? :) Or maybe the one on Eutopia main should be just called Signal, since it's the same code? |
|
It can't be named Signal: https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png |
|
okay then what about the other idea? or other ideas period? |
|
App description in the experimental repo contains the note about WebSocket |
|
A suggestion: FreeSignal (written as one word) is a name that has not been used yet (OpenSignal is already used). So name the version that uses GCM FreeSignal instead. Make sure that both projects have a clear description of how they differ, and a link to each other for those who are interested. Or better yet: let them both link to the same document that notes the differences in terms of requirements, functions and limitations. |
|
Maybe CustomSignal ? |
|
TextSecure build were named TextLibre. Maybe let's name it TextLibre? |
|
That would add more confusion, since TextLibre is also the name of an older project. At this stage, I think it would be best to avoid reusing names. We are trying to reduce confusion, not potentially increase it. FreeText as a single word is not used for an Android application yet (as far as I see in the Play Store). That name could be used for the WebSocket version in this repository (which does not support voice calls). Alternatively, LibreText is also available. Or maybe LibreSignalText, to still have the indirect association with Signal and more explicitly that it concerns text messaging only? |
|
Since @xmikos is the maintainer of the Eutopia repo, I think he should decide about the name... |
|
I am just providing suggestions and my opinion, and am not saying who should make a decision or what the best choice is. That's up to you guys (both working on 'LibreSignal'). |
|
I definitely want this project to stay being named LibreSignal. But we clearly need to differentiate it from builds from original Signal source. Many people using my repositories are accustomed to LibreSignal name (for both original and WebSocket builds), so I want to keep this name. But I can add some identifier to the name, like "LibreSignal (GApps)" or "LibreSignal (WebSocket)". What do you think about this option, does it seem sufficient for you? |
|
The name in F-Droid of the WebSocket fork already contains "(WebSocket)". As for the name of the installed app, I think it shouldn't be to long... |
|
I know, but build from original Signal source doesn't contain "(GApps)" and like we now see, it is apparently confusing people. Maybe WebSocket build should be simply named "LibreSignal" (to be consistent with this project name) and build from original Signal sources named "LibreSignal (GApps)"? |
|
Maybe the name of the installed application can simply be LibreSignal for either. Add a suffix, such as "(WebSocket edition)" and "(GApps edition) to the name in the Advanced screen and all references outside of the application on the web (such as names in F-Droid). |
|
There already is difference in the long description on F-Droid. And it is explained on https://fdroid.eutopia.cz website. Apparently some people don't read that... |
|
Quoting myself:
|
|
Yes, that is in the descriptions. And that supposedly still is confusing when discussing "LibreSignal", as per this issue. It still is unclear for people which version they should install for which functionality. See the top post.
Which is why clarity and consistency are so important. "LibreSignal" is ambiguous. Referring consistently to "LibreSignal (GApps edition)" or "LibreSignal (WebSocket edition)" (or something similar that is easy to distinguish when reading and writing) would reduce the confusion. |
|
LibreSignal in the main Eutopia repo = custom build of Signal from OWS. |
|
Regarding that Eutopia build - why is it a rebuild at all? Why not just ship the Signal binaries as is and update them with gplaycli or something? That would resolve the issues raised by Moxie in the aforementionned discussion ("you are forking TextSecure"). |
|
Oh, and I support the "parenthesized distinction" that was suggested. I think it would be more clear to call them:
... however. Also make it clear in the package's metadata descriptions that the Websocket version is an actual fork while the GCM version is just a rebuild. |
The Signal binaries from the Play Store do not work with microG. The rebuild provided by @xmikos does. I don't know why the rebuild works with microG, but I would appreciate it if they are kept being offered as they are offered now. If name length is an issue, change "LibreSignal (WebSocket)" to "LibreSignal (WS)". |
|
@anarcat It is important for me to provide independent build from source code, because Open Whisper Systems (US company) can be sometime in the future forced to silently push backdoored update. I review diff of source code before every new release (this is also why it sometimes takes longer before I publish update on eutopia.cz repo). |
|
Ok, it looks like I misunderstood it. I thought Signal users will be able to talk with whatsapp users using signal application like LibreSignal. Thanks. |
|
Wow, what a discussion. I thought it was rather simple.
right? |
|
There are two flavors: only rebrand, WS instead of google-GCM MicroG instead of Google-GCM ----> #30 |
|
@h-2 Well, there is another complication :-) There are two builds of LibreSignal (WebSocket):
They are same otherwise (just different appid and signed by different key). |
|
@xmikos wait - so the experimental repo has the same appid has the official build? that sounds wrong... i thought that build was exactly the same as org.libresignal from github. |
|
The only diff is that he 'sed' (Linux command) the package name in build.gradle. |
|
@anarcat My repositories predates LibreSignal project on GitHub. I can't change appid because everyone using it will lose app data (private keys and history) in that case. And it would also mean that nobody can switch from Signal to LibreSignal (with help of oandbackup) without losing app data. |
|
I think it's probably acceptable to switch just once, now, while not that many people are using it yet. Otherwise it can only cause trouble in the long run. |
|
@d9h02f I assume that people will switch to official F-Droid repository once LibreSignal will be in it. That would be another lost app data for them (because of different signature). I will not change it in my repository. Btw. @mimi89999 how does it look with it? Do you know why is it not in main F-Droid repository yet? |
|
No, I don't. @krt16s or @mvdan should know. |
|
For the record, I switched from LibreSignal (Websocket) to Signal (official) without "loss of data": i unregistered, backed up the text messages and restored. The keys changed, but meh, i was a new user. regarding switching to the official F-Droid repo, I wouldn't do that, personally, because that would mean loss of functionality (voice calls), if i understand correctly. |
|
Why is LibreSignal not in F-Droid mainline? Well, the main reasons for not publishing to mainline were:
So, where do we stand now? I think 2 and 4 are fixed. 3 would still be a lot of work, especially we need to decide which version is "upstream". 1 depends a lot on your personal view... while I wouldn't mind having LibreSignal in mainline, I don’t want to be the guy to decided this. I pushed Firefox/Fennec prematurely to mainline and it broke some builds after. I exposed users to a security risk, left them with an unpatched browser. While it had an equivalent warning in the description, still users put the blame on me..and they did so rightfully. So what to do: Open a merge request removing the warning and the |
|
For 3. we should first make the build reproducible (there were problems with NDK code). I think that it is very important that the version in F-Droid is verified... The problem is who will be keeping the keys. |
|
I'm a Signal user who's just come across LibreSignal, PhoneLibre, et al, for the first time. Even after reading this thread, I was confused. Then I went and added both eutopia.cz repos and look at what was in them, and now I think I am clear on the relationships between the different apps.
I think the most logical place to split the naming is between apps with the thoughtcrime id and apps with another ID. Then the question becomes, "Who should change their name, and to what?" I included PhoneLibre for a reason: it uses Libre as a suffix instead of a prefix. I think this is the most logical split. One app can stay "LibreSignal" and the other can become "SignalLibre" (or Signal-Libre if you think the double L is weird). @xmikos I know you've said you don't want to change the name, but obviously somebody's name needs to change, so I hope you'll reconsider: I think it would be the minimum hardship overall if all apps that keep the thoughtcrime id use the prefix, while this repo keeps the suffix. On the eutopia.cz, the only thing needed is to change the name of two packages. On this side, the name, the appid, the github organization name, and the github repo name would all need to be changed. We'd also be following the precedent set by SMSSecure: a different prefix means it's a fork with different maintainers and a different namespace. |
|
@smichel17 Let me correct you:
|
|
@xmikos The link to JavaJens fork in the app description might be confusing. |
|
Wait for #32 |
|
edit: just re-read this thread and I understand now. edit2: I will stick by my original suggestion. I think -Libre as a suffix should indicate apps that are striving for backward compatibility with Signal (particularly, via use of the same appid), and Libre- as a prefix should indicate apps that could be used alongside Signal or could one day diverge and become incompatible with Signal (regardless of whether they are currently aiming to be inter-operable). edit3: particularly since per #20:
edit4: I believe my suggested solution is superior because in its case, the only confusing piece will be why SignalLibre (WebSocket) is not named simply LibreSignal. Users will only ever run into that confusion if they are already viewing SignalLibre and then they go to view its source. Since there's only one place that they might be confused, it's really easy to include a note right there that explains the difference, preventing the user from being confused in the first place (as opposed to trying to straighten people out after they are already confused, which is a mess -- see this thread). |
|
@xmikos @mimi89999 bump because when you edit comments it doesn't send new notifications. |
|
LibreSignal in the Eutopia experimental repo = LibreSignal in the F-Droid archive repo. |
|
@mimi89999 I will change description with next update. I will also update name of build from official Signal sources to "LibreSignal (GApps)" @smichel17 Sorry, but I think that switching name from LibreSignal to SignalLibre will only add to confusion. This is not what I want to do. |
|
I will add a FAQ ASAP... #32 |
|
Please see the FAQ, that I just wrote. |
|
i tried to make a table in the FAQ to clarify this, because i was still confused: https://github.com/LibreSignal/LibreSignal/wiki/FAQ#what-is-libresignal-in-the-eutopia-repository |
|
@anarcat Thank you. |
I spent a large amount of time working with this project without understanding there are two completely different projects here:
org.thoughtcrime.securesmsorg.libresignalThis leads to really confused discussions like #10 where we have no idea what we're talking about when we say "LibreSignal".
Can this confusion be cleared up? It seems to me the solution would be to rename one of the two projects.
Thanks!
The text was updated successfully, but these errors were encountered: