Mastodon VS matrix-react-sdk

Interestingly there is some discussion for Mastodon with people asking the limit to be smaller, which raises the question as to the purpose of alt text, and how to properly handle larger text lengths in screen reader programs.

https://github.com/mastodon/mastodon/issues/12268

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

Mastodon DMs have absolutely no privacy: https://github.com/mastodon/mastodon/issues/18079

For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.

Postmortem on what happened here: https://news.ycombinator.com/edit?id=39305884

The v1 API of Mastodon limits the size of the tree that it will expand for users who are not logged into the server: https://github.com/mastodon/mastodon/blob/main/app/controllers/api/v1/statuses_controller.rb . I am guessing that this or some similar limit applies to threads being returned to unauthenticated users of the web UI. It just arbitrarily stops expanding the replies at some point, including the main thread from the OP.

If a thread is truncated, users expect it to expand automatically and autoscroll when you hit the bottom. In my desktop browser, that does not occur, and there is no indication that there is more to see. This is the situation of the web interface as of Mastodon version 4.2.5.

The issue is very sensitive to observer conditions. If you are logged into the server, the behavior is different. If you use a Mastodon app instead of the web, the behavior might be different. As the tree expands, the cutoffs become different. If you look at the thread on a different Mastodon server, the tree is different because every server has its own view of the Fediverse.

HN needs a best practice for linking to Mastodon threads in a way that provides a consistent experience to HN readers. The average Mastodon server would be crushed by hundreds of HN readers grabbing the entirety of a huge thread all at once, so this might involve some thread-unroll-and-cache service. I tried https://mastoreader.io/ but it did not solve the problem.

Alternately, we push changes into the Mastodon web UI to warn users when they need to click to see more and assume that people will get used to the navigation.

Suggestions?

Fixed in Mastodon v4.2.5 https://github.com/mastodon/mastodon/releases/tag/v4.2.5

>You can defeat the Affero clause by putting the software behind a proxy, for example

Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?

[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

Mastodon is free and open-source. Go ahead and add the flag:

https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....

Didn't say anything about freedom of speech. And again: I'm not the one to talk to. I don't have any strong feelings on the topic, but if you do, you should take it somewhere that people who can do something about it will see.

I tried to find an existing discussion to help get you started, but couldn't. You can start one here: https://github.com/mastodon/mastodon/issues

It's easy to sit here on Hacker News and say "they should just..."

Coming up with a standard for an international project will be a long, noisy discussion. You'll tread on internecine conflicts you had no idea about. Old wounds from past related discussions will come out. People will soapbox.

This is why I have no interest in discussing it. It probably won't go anywhere in a place where it actually could. It definitely won't here.

There's already an (old pull request)[https://github.com/matrix-org/matrix-react-sdk/pull/9240] out for custom emotes for the element client but is blocked by acceptance of spec and other minor issues with code style.

You are completely misinterpreting my quote, which makes me question whether you are acting in good faith.

Totally agreed that Signal servers cannot just add a device to a group chat.

What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action.

The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate.

> I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.

Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the previous one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.

1. We are about to replace the composer in Element with a sparkly new (optional) wysiwyg editor in the coming weeks: https://github.com/matrix-org/matrix-wysiwyg

2. totally agreed. we are completely reworking the crypto UX; there’s already https://github.com/matrix-org/matrix-react-sdk/pull/8228 asa proof of concept of what’s to come.

3. glad you like Cinny - it’s written by ajbura, whose dayjob is at Element and built the UI for Third Room. Element is not “the official app” - it’s just the one that happens to be written by folks from the Matrix core team. If you prefer Cinny, knock yourself out. Meanwhile we’re frantically improving Element too.

Unlike any open source projects to which I've contributed, this project involves 2 other repos, matrix-react-sdk and matrix-js-sdk. As explained in the Development guide in the element-web repo, I need those 2 SDKs in order to build Element successfully for code contribution.

> Also, you can do toggle mute via hotkey (which we have a draft for at https://github.com/matrix-org/matrix-react-sdk/pull/2280), but this is surely a bonus feature.

Proper Push-To-Talk with global hotkey is one of those features that doesn't seem important but when you need it (organizing Raids in games, big meetings, etc) it makes a world of difference. That and lack of click to join voice rooms is definitely making it harder to move gaming groups over.

Encryption is now enabled by default for 1:1 chats. There's an MR for adding GIF support but looks like they are not interested in it.

This is a really common failure mode - people forget to explicitly assert that the other modifiers are off when checking for a modifier being on. I had to go through and fix all the ones in matrix-react-sdk (element web) a few years ago: https://github.com/matrix-org/matrix-react-sdk/pull/825/file...

Exposing the desktopCapturer to the render process and then using it inside the web app