Open relyt29 opened 8 years ago
Like I said above, I think this repository should remain a simple fork. Also, I think that any maintenance of more features, like a complete Google Free version, should be managed by some organization. Whoever feels like it can and probably should create this organization. Also I think I am not the right person to make any decisions here. I don't use this version here and I can't get too involved atm on anything that goes beyond testing a PR or helping out a little.
Regarding running your own server: First, I don't know if we would have to do this. But if so, I think running the server is not too difficult, I did this a while back for development purposes. However, you have to think of the financial side there: you need AWS, Twillio etc.
Plus, I think there is only one solution to do this: talk early and often with OWS in a way that this server can federate with them!
@mimi89999 Yes, there are references to this throughout the code. You could try to get the interfaces that are used and implement an empty version of it (see https://github.com/mar-v-in/NoAnalytics/)
@SecUpwN
so that the userbase won't be split and yet another "fork of the fork of the fork" is being created.
LibreSignal organization could clone Signal-Android, PR from this repo and remove GMS.
I reverted location in my repo: https://github.com/mimi89999/Signal-Android Now I only need to remove GCM. :-)
Can I create the "LibreSignal" organization?
I think pulling from this repo is not as good as transferring the ownership (issues are lost, no HTTP redirection). So it would be nice if @JavaJens transferred this repo to the "LibreSignal" organization as soon as created.
@mimi89999 Go ahead :smile: I think a direct clone might be even better? Searchable etc. But we can see.
I need help with removing location: the build fails an I can't figure out why.
@mimi89999 Best would be to open another issue. I try to look into your repo, to see what you did.
For one, I wouldn't revert the complete commit. Just the parts relevant to location
I reverted the commit, but in my last commit I re-added the changes.
Like I said above, I think this repository should remain a simple fork.
How come, @JavaJens? There already exist several great blog-posts about LibreSignal
(especially on the largest German security blog with the article Android: Signal ohne Google Cloud Messaging). I don't see what would be your or anyone elses problem when elevating this repository to what it deserves.
Can I create the "LibreSignal" organization?
Wonderful to see your enthusiasm, @mimi89999! But I fully agree with what @dotlambda just said in https://github.com/JavaJens/TextSecure/issues/72#issuecomment-188576946, I'd really prefer that option. If @JavaJens is not able to fully dive into maintaining all aspects of this repository and unchaining its full potential, it would be wonderful if he did the following:
LibreSignal
under which all work will be continuedLibreSignal
and move it into the new LibreSignal
organization@SecUpwN this repo is a fork, and will be penalized in github search(perhaps in google rankings as well). A "direct clone" would fix that. Continuing to use this repo for a full project would not. I believe that's what @JavaJens was getting at.
I'd suggest creating a new repo in that new org where work could continue. Perhaps @JavaJens could transfer this old repo as well (for posterity), but that's not necessary. Someone with collaborator status could use this issue mover tool for issues that are still being discussed:
I think keeping the fork relationship with upstream will make it easier to PR from upstream to update...
@mimi89999 Feel free to create this organization. I feel I wouldn't be a suitable creator as I don't have the time right now. I just think that a fresh start is better and it shouldn't matter for updating, just add upstream as a remote. I can transfer the ownership afterwards, np.
I don't have my PC with me ATM. I will do that ASAP...
I created the organization.
@mimi89999 I saw you forked from upstream there? How do you want to proceed?
I want to add libtextsecure-java as a submodule and then PR from here.
LibreSignal is almost ready. I need help with testing.
Re: "I need help with testing" Yesterday i installed LibreSignal 3.12.0-websocket via f-droid repo https://eutopia.cz/experimental/fdroid/repo and everything worked smooth so far. Thanks a lot! Where is the best place to follow up on this?
Thanks a lot! Where is the best place to follow up on this?
@altergui, the best place to follow up is @LibreSignal. :smile_cat:
@SecUpwN Still no reply from Snowden (https://mobile.twitter.com/AIMSICD/status/679814924516880384)
@mimi89999 and all, feel free to re-tweet my tweet with a new question, but don't expect a reply from him. Not sure if @ioerror is in touch with him and can respond here (which would be lovely). But in my eyes, Edward Snowden does not seem to be that eager to justify why he trusts that Google library. Too bad, because this is an essential question I'm sure many would like to see Edward officially respond to.
feel free to re-tweet my tweet with a new question
I can't do that because I don't have a Twitter account and I don't want to create one.
In case someone didn't follow the discussion over at LibreSignals issue tracker... I think this sums up OWS' relationship to "unrelated forks" pretty good:
After #71 is solved, we need to come to the following decisions moving forward:
A) Do we acknowledge this repo as the source for LibreSignal, or do we tell @xmikos to create his own repo, and stop sending people with issues our way? If we acknowledge this repo as the source for LibreSignal, what level of support do we provide to people posting issues?
B) Do we start incorporating new feature requests that diverge with upstream, e.g. #40.
We should decide these issues one way or another, and then address the repo in that direction. If we decide that we still want to remain as close to upstream as possible, then we should close the offending issues, tell @xmikos to stop pointing at us for support, and start working on getting merged upstream, whatever that would take. If we decide the opposite, then we should merge #40, perhaps start working on LibreSignal features, and make it more transparent how LibreSignal releases are being made.