That's a fair criticism. I prefer using Session with better multiple device support and without waiting for Signal to finally stop using phone numbers.
When using either, disappearing messages should be enabled.
The part about PFS falls down, for me, when you assume both that keys can be cracked in some shorter than normal time-frame, and that the new key (per message, or less often) won't also be cracked quickly.
I could have guessed that you used Android before your previous message simply by your positive impression.
Try switching the OS and keeping your messages then you will discover the difficulty. It's worse if you began on iOS.
I just recently had the Signal servers silently stop communicating with the app. I had to create a debug log to find that the server was sending an error for some reason when it was working the previous day. Switching apps was the only solution remaining.
Signal fails as a useful solution as long as:
- I can't switch devices and keep messages.
- I must give them a phone number.
- Multiple devices can't cooperate to allow me to chat continuously from any device.
- Messages can't be sent/received arbitrarily because the server decided my client isn't acceptable.
Signal is not reliable and very user-hostile.
I think most iOS users have no trouble understanding how user hostile Signal has been after getting a new device or losing all the messages they wanted to save.
As for the user base, that's a problem that fixes itself as more people switch away from Signal.
For Signal, they will know when and how often you receive Signal messages.
Notifications are used to "activate" the app on your device. Then it will connect to Signal servers and download the encrypted messages.
After the software on your device decrypted the message, then it has the sender details and message content.
There are settings to control how much of that information is used when creating the local notification. Because other apps might log notifications.
That's terrifying for showing how little he understands about the problem he is attempting to solve.
Humans use up to four senses at times to accomplish the task of driving.
As for selecting an instance, if that is a barrier, then forcing users to create and use multiple accounts in different ways to see all the content they want to is an even larger hurdle to present to users.
One of the biggest problems with Mastodon is new users who think they need an account on every instance website they interact with.
At best, it's an opportunity to organically introduce other types of content and the associated software to people through the social graph they chose to participate in.
If you did as you suggested, by adding posts / threads / communities / magazines without the consent of the users, that would indeed be a problem.
Preventing Mastodon users from seeing the content after they made the choice is also a problem.
I take it you weren't aware that Google Wave was based on XMPP.
> How do they manage to make the same messages appear on multiple devices?
For a long time, they didn't.
I don't know for sure, but I expect it involves keys that multiple devices share. Any "linked" device would be able to download the encrypted copy and decrypt the message that way. Once any device has done that, it can send a copy to any other devices using the unique keys it knows for that device.
This link describes independent queues for devices: https://support.signal.org/hc/en-us/articles/5532268300186-Disappearing-Messages-with-a-Linked-Device
> Signal stores all your messages and media as well, the difference is they encrypt it on their servers.
What evidence do you have to support this claim?
The last time I looked into this, messages and media were only stored encrypted on servers until they were retrieved or expired.
After that, the local device is where things are stored.
This is a good video explaining things, for anyone who doesn't know about the situation Apple created.
https://youtube.com/watch?v=BuaKzm7Kq9Q
Alternative 🔗:
https://yewtu.be/watch?v=BuaKzm7Kq9Q
https://piped.video/watch?v=BuaKzm7Kq9Q
Eventually, the list of things Samsung doesn't make is going to be shorter.
I understand the point you were trying to make. You're just wrong, in my opinion.
You are also focusing on the wrong software.
Mastodon, as the place most people start with ActivityPub software, absolutely should be able to view other types of content.
The important point is to not force anyone to view that content or display it particularly badly.
When all I know about Kbin is that it doesn't work with my Mastodon account, why exactly do I use it?
Why don't you ask the Matrix team why they decided to re-invent XMPP and add a stupid HTTP API?
It's both amazing and annoying that Google is perfectly able to create useful apps for iOS (despite the huge limitations the OS imposes) but Apple can't figure out how to make any Android app that isn't utter crap with fewer restrictions imposed on them.
> Technically we are federated, so why do Mastodonians interact so little with the Threadiverse?
I have a much simpler answer to this. Kbin doesn't allow me to follow (or even view) a lot of the content. Lemmy does better at this.
To be useful, I need to be able to follow magazines / communities without resorting to a web browser that doesn't have my account (and often won't show me the content).
The up voting mapping needs to be consistent too!
As a Mastodon user who follows Lemmy posts, I find Kbin integration insufficient to the task.
I want to read link aggregator posts in my Mastodon app, not a web browser.
As for long posts, Mastodon handles those just fine. App developers know there isn't a universal limit already.
Chris Ely @fosstodon.org IT enthusiast. TV addict. A systems admin / tinkerer, who is also curious about development, network and security fields.
I created this account on leap day 2020, but I didn't use it nearly this much before Twitter was purchased.
\#tfr #tootfinder https://justmytoots.com/@tcely@fosstodon.org https://www.topmastodonposts.com/by/@tcely@fosstodon.org
\#GreenNuclearDeal🌿⚛️⚡🤝 @tcely
Backup account: @tcely