131–140 of 217 posts
Earlier quoted context omitted.
I had a hunch … so I opened a German to English translator and put in the words Cyber furz In English: Cyber fart Every day is a school day!
It's not German, it's a furry instance with some 90s flavor.
Earlier quoted context omitted.
I think that's one approach, but many other federated systems don't do this. ActivityPub does not do this really, instead Mastodon, a product using ActivityPub, markets itself. Arguably you could look at HTTP and say that HTTP doesn't have a fancy landing page pitching itself to users, browsers have landing pages pitching their experiences to users. Matrix could have a fancy landing page pitching itself to implemente…
Maybe "Matrix" is not the ideal name for it then. ActivityPub, HTTP, XMPP, etc sound like technical things. If you land on a page talking about the "XMPP specification" then you quickly get the idea that it's not where you want to be as an end user. "Matrix" does sound a lot like the name of an end-user relevant product of some sort, and a client sending users to matrix.org compounds the issue. There's a reason why b…
The client I use doesn't send users to matrix.org, and I would assume that's by choice. Why do users need to know? Matrix.org is clearly a hub for the spec, documentation, GitHub links, developer community.
Earlier quoted context omitted.
But Matrix isn't a product. There are companies building products on it, such as Element and Beeper, and as far as I can see the latter are doing a perfectly good job of selling themselves.
That may be technically correct, but reality is if Matrix wants to catch on (large scale) as a concept, it needs to act as a product in some way. Even if that just means having a good landing page guiding users on how to sign up on a server, install a client, and connect the two - and making sure that this always works.
We definitely aim for Matrix-based products to be used by the general public, in the same way emails are. For this to happen, we need to be mindful of who our audiences are, what they are looking for, what they know and don't know, and how to deliver a message that works for them.
If you're interested in how we thought the website, you can check https://github.com/matrix-org/matrix.org/issues/1502 and https://github.com/matrix-org/matrix.org/issues/1543 for example
Earlier quoted context omitted.
Cinny is the Matrix client that copies Discord's UI. My friends and I use it as the default web interface for our private server, no complaints (other than the fact that it makes you appreciate Discord's sometimes-annoying "join all channels by default" feature; the opposite, classic IRC approach of forcing everyone to search for and manually join all channels scales better but is an absolute disaster for discoverabi…
This bothers me just as much in Discord as it does Slack/IRC. Has any chat software figured out this problem yet? Surely there must be some middle ground, like optional channel categories or something.
I wish they had a built in way, & also some way to make channels line bot_commands default to muted
This kind of process is extremely valuable and should be done by devs more often. Start from the start and follow whatever your application tells you to do . Note down when it doesn't tell you where to go or what to do. You'd be surprised by just how many things you do automatically while working because you know the little tricks and things to get by, and that wording doesn't necessarily match what the app requires…
Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time. This kind of article is s…
Thanks for working on matrix, I'm building some things on matrix and it's been pretty interesting.
> For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.
Great highlight, I've donated.
This kind of process is extremely valuable and should be done by devs more often. Start from the start and follow whatever your application tells you to do . Note down when it doesn't tell you where to go or what to do. You'd be surprised by just how many things you do automatically while working because you know the little tricks and things to get by, and that wording doesn't necessarily match what the app requires…
Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time. This kind of article is s…
Earlier quoted context omitted.
Matrix and Element are no longer the same entity. Element (New Vector Ltd) is the core behind the Matrix protocol, but they're distinct from the organisation that manages the protocol. If Matrix does ever take off, this will be an extremely valuable distinction to have.
I understand that completely, I even considered including a "Before anyone jumps in with 'akshually that's Element', [..]" disclaimer but decided nobody would be that pedantic. Element is the same team as the Matrix.org foundation, with the same objectives. I understand why they maintain a separation of concerns at the institutional level, but for someone to say "Matrix offers hosted servers" and to act confused like…
They're mostly the same people (80% of the core spec team works for Element), but not exactly the same people. The Element people that maintain Matrix certainly have a vested interest in Element, but that doesn't make Matrix exclusively Element-oriented.
While you and I understand the distinction, I think it's important to make it clear to other readers here that Element and Matrix are not the same organisation. Because of Matrix's history, and the interlinking between matrix.org and Element, one might assume them to be, and if the opening post shows anything, it's that the Matrix ecosystem can benefit from some additional clarity.
Earlier quoted context omitted.
You can if both devices are phones and you are physically in the same location. Otherwise, the user is expected to be able to do that. In any case, the user won't have the faintest idea of why they have to do that, so they won't, which in a sense makes this moot.
> Otherwise, the user is expected to be able to do that. If you're not in the same location, you can long press the code in Signal and "compare to clipboard". > In any case, the user won't have the faintest idea of why they have to do that, so they won't, which in a sense makes this moot. I think that's a generic remark about this though, that applies to all messengers AFAIK. Whether that's a 4-digit code and 60.
My point is that users should have the chance to know what they are doing. There seems to be a tendency to deliberately keep them in the dark. A 4 digit code is objectively more usable than a 60 digit code.
Earlier quoted context omitted.
QA is a massively underappreciated position. A QA person that knows when to automate, when to manually test, and how to report and file issues relevant to the project can save a significant proportion of hours on a project overall. I wish many more companies included budget for QA, it saves developers a lot of time. A bit of a side-note: this sort of analysis is a great answer to "I want to contribute to open source,…
Good QA people are hard to find and it's a weird balance to strike. I've seen QA get run over by aggressive developers. I've seen QA people who were so good, detailed and provided clear reproduction steps that developers couldn't wait to see them work. I've seen QA people who were completely unwilling to work on efficiency improvements, automation or even testing things in parallel so they became a bottleneck to the…
Earlier quoted context omitted.
No, they aren't the same team (anymore), and there isn't just Element as a service provider
And yet Thib, mentioned in the article, does say in an another comment that they are employed by Element but working for The Foundation, making it quite hard to know the difference between the two: https://news.ycombinator.com/item?id=39369239 If you dig a bit, I'm sure you'll find this is true for quite a bit of the people either in Element or in The Foundation.
https://matrix.org/about/ has a list of names for the "guardians" of the foundation (whatever that may mean exactly) which consist of 40% Element, 60% external parties. The core spec team at the bottom links to Github profiles, from which I believe 8 out of 10 people work for Element (though I'm not 100% sure if the last person in the list still works for them based on his Github profile tag).
Thib isn't part of the foundation, he's just part of the business side, and quite a public part at that. I think his role is a good example of the distinction between Matrix and Element.