search

JavaJens / TextSecure

A secure text messaging application for Android.
GNU General Public License v3.0
72 stars 9 forks source link

Import SMS from SMSSecure #53

Closed SecUpwN closed 8 years ago

SecUpwN commented 8 years ago

Hi there, me again! This will be my last Issue on your repo for today, promised. I am currently playing with LibreSignal and would like to import my SMS from SMSSecure, backed up in cleartext. Seems like LibreSignal does not recognize the backup file yet, would be lively if it did in the future. Also, maybe it would be possible to add support to directly import the SMS from SMSSecure while it is unlocked? Thanks for considering all these things. Cheers and greetings from Germany!

JavaJens commented 8 years ago

Please see my comment in #51: I don't want to implement any new features here.

SecUpwN commented 8 years ago

I don't want to implement any new features here.

@JavaJens, it is not a new feature, it is an enhancement. I have investigated this and found the simple solution: The backup from SMSSecure does not get accepted just because its file name is SMSSecurePlaintextBackup.xml - renaming it to TextSecurePlaintextBackup.xml makes it get accepted by LibreSignal. Please re-open this Issue and add some liberty to accept other backup names.

schachmat commented 8 years ago

It is however not an enhancment to the websocket support, which is the sole purpose of this fork.

SecUpwN commented 8 years ago

It is however not an enhancment to the websocket support, which is the sole purpose of this fork.

So where to file this Issue then? And if users shall not file Issues related to anything other than the websocket support, please add a CONTRIBUTING.md and mention it on your README at Contributing Bug reports. This limitation, however, makes me feel like people are not wanted ro contribute much here.

relyt29 commented 8 years ago

The point of this project is to develop a method for people without Google Play to use TextSecure on their devices, and then merge that code back into upstream. It is not to develop the "ULTIMATE" fork, or add new features beyond that. That would increase the already sizeable diff between the two codebases and make it harder for us to merge. Similarly, I don't think we'll be changing the README or CONTRIBUTING.md files because again, that would increase the diff.

So where to file this Issue then?

You seem to be using "LibreSignal" the download of the codebase that @xmikos took, put on f-droid despite moxie's request that people not put Signal on f-droid, and then got into a fight with moxie on twitter over naming bs. Perhaps you should take it up with him, and request that he makes a software repository on Github for people to contribute random feature requests for which could then take the codebase off in a completely different direction from upstream, and make it ever harder to merge.

Or you could file a feature request upstream and see if you could convince Whisper systems to develop it into the actual upstream product. If you take that route I recommend posting on the mailing list as that seems to be where moxie and co like to keep discussion for new feature requests as opposed to Github which is for bug squashing.

Lastly, you could actually put some hard work in yourself, instead of asking other people to put in hours of their life for free for your personal feature requests and create your own fork. You would then have to develop the features yourself, and then take responsibility for maintaining the software, pulling in updates from upstream, and making sure the codebase doesn't become stale.

See here's the thing people don't get - it's not just about writing the code - its about writing the code and then being responsible for keeping it alive and fresh.

But that's a lot of work.

Hence why Moxie is so hesitant to accept anybody's code contributions - he gets stuck taking responsibility for it. It's also why we want to merge back into upstream some day - because its a time and energy drain on my part to have to keep this fork alive in the meantime while we figure out how to get the code polished enough to get merged back upstream. Once its merged upstream, it becomes upstreams problem to keep the codebase alive.