It should’ve been a layer of encryption over SMS and remain otherwise stateless and platform agnostic.
Umm what?
SMS has a very short size limit. Implementing RCS as an encryption layer on top of it would require devices to send several messages just to cover a short one-word reply. They also often come out of order so they would need to include a numbering system so the client could piece them back together.
Granted that is already how SMS works on modern devices, but the underlying protocol is woefully inept at modern messaging and completely unviable for what you’re proposing.
How should media attachments work? I assume you expect that to just use encryption built on MMS? So media can come through even more compressed than basic MMS? None of the actual benefits of RCS would be possible if it was built on top of the existing ancient standards.
Encrypting doesn’t necessarily boost the size of the message. You can also use compression very effectively since it’s mostly text.
You don’t need to also solve media hosting, you can just leave it be links like it is now. Just adding encryption would be an amazing improvement.
There are no additional changes needed to the transport layer, it would be transparent for telcos. It can be an OTG encryption layer.
Initial key exchange would be the only part that would require a couple of additional one-time messages but it would be automated. And not all messages need to be encrypted, nobody cares that my package has been shipped. And it would be an improvement anyway from having zero encryption to being able to have encryption
The whole thing is so simple that it could be implemented today by all the SMS apps without missing a beat. The only thing missing is the willingness to do so.
In fact it could be added as an option in any SMS app very easily — only for people who are both on the same app of course.
Umm what?
SMS has a very short size limit. Implementing RCS as an encryption layer on top of it would require devices to send several messages just to cover a short one-word reply. They also often come out of order so they would need to include a numbering system so the client could piece them back together.
Granted that is already how SMS works on modern devices, but the underlying protocol is woefully inept at modern messaging and completely unviable for what you’re proposing.
How should media attachments work? I assume you expect that to just use encryption built on MMS? So media can come through even more compressed than basic MMS? None of the actual benefits of RCS would be possible if it was built on top of the existing ancient standards.
Encrypting doesn’t necessarily boost the size of the message. You can also use compression very effectively since it’s mostly text.
You don’t need to also solve media hosting, you can just leave it be links like it is now. Just adding encryption would be an amazing improvement.
There are no additional changes needed to the transport layer, it would be transparent for telcos. It can be an OTG encryption layer.
Initial key exchange would be the only part that would require a couple of additional one-time messages but it would be automated. And not all messages need to be encrypted, nobody cares that my package has been shipped. And it would be an improvement anyway from having zero encryption to being able to have encryption
The whole thing is so simple that it could be implemented today by all the SMS apps without missing a beat. The only thing missing is the willingness to do so.
In fact it could be added as an option in any SMS app very easily — only for people who are both on the same app of course.