bad code replacing

[novazur972]

Google translate: Hello, I would like to point out to you a very very penalizing bug for all the inhabitants of the French overseas departments. Indeed, we use a rather particular telephone system, because although we are all in France, we each have our own international code. France is +33 But Martinique for example (where I am) is +596. However, our French telephone system replaces this international code with a national 0. My number is recorded in signal in international format + 596696xxxxxx And when I receive a call from mainland France, signal transforms the 0 into +596 (which is my own callsign) but which does not necessarily correspond to the number of the person who sent me this message. The sender's number is therefore FALSE. And if I try to answer him, I must have an error. To achieve this, I have to send my message by replacing the +596 with a +33 manually. You will agree that it is far from very practical. Thank you in advance.

[greyson-signal]

Not really sure what the best way to handle this is. Signal assumes all of the phone numbers that we work with are properly e164-encoded, which requires a country code. If a number has no country code, the only thing we can assume is that it must be the same country code as the user's own number. But that isn't correct in this specific situation.

It sounds like France's telecom system has special rules setup for the interactions between +506 and +33. It seems the only way we could allow those rules to apply would be to send to the unmodified number when sending SMS/MMS instead of the e164-formatted one. This just really doesn't fit into our system well and adds a layer of complexity. I'll think about it.

[AnAkkk]

I have seen the same issue, and this bug is not limited to normal phone numbers. I have received an SMS from an online service, and the phone number was just a 6 digit number (e.g. 647469). Signal has added a +33 in front of this number, which is wrong. Receiving the same text without Signal shows no country code, which is correct.

I was not in France (but UK) when receiving the text and it doesn't come from a French service anyway, so it makes no sense to have a +33.

[driuba]

I've been reading through several issues about this since I had problems with service numbers. I can sort of understand the reason as to why Signal is assuming and guessing country codes. However, in my opinion, any amount of guesswork here is inherently bad and if it is really necessary user should be able to override it if he so desires.

If I'm entering a number, I don't expect anything to be modified about it. Same goes for recieving messages, if I recieved a message, I don't expect additional modifications to recipients' information.

Many of these issues can be resolved just by allowing manual override if Signals' guess was wrong. Granted, it would introduce new issues to which I don't have solutions.

As an SMS app Signal seems just plain old broken. I intended to switch to it, mainly because it supports SMS, so it wouldn't be just another messaging app. Honestly, why bother with supporting a feature if it doesn't work half of the time? It would be very appealing having Signal function as a SMS app for any new user, however, as it is now, it lacks key features, like SMS history import, and features it has are somewhat crippled. I get that SMS is not the main focus of Signal, but then it should not be there at all if it's not implemented correctly.

Edit:
grammar

Edit 2:
So I thought about it a little. From functionality standpoint I, as a user, should be fully responsible for data correctness. Now we have an app that limits valid use cases due to some internal logic. The app already has a mechanism to check if number is a valid Signal user and, if he isn't, app leaves SMS functionality enabled. I see no reason why auto-prepended country code cannot be made editable and optional, so that when validation fails only SMS functionality is available. It shouldn't be a big change and would solve all of the related issues.

Now, one issue I see immediately is, what if I chnage the number of one chat and another chat is already existing. I see two options - delete one of the chats or merge them, preferably user selectable choice.
Megreing might be more difficult than I imagine, but that's just implementation details and it could also be rolled out separatelly.

I don't know, how the app is handling chat saving, but I imagine most of the stuff, can be done clientside. If I had more time, I would muck around the code myself, but I can't right now.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[AnAkkk]

Still happening.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[driuba]

Still relevant, short numbers e. g. 4 numbers, get prepended with country code. The result – can't send messages to service numbers.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AnAkkk]

Still happening.