_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Matrix.org Will Migrate to MAS
barodeur wrote 9 hours 41 min ago:
Congrats to Quentin and all the other contributors to this project.
sanatgersappa wrote 16 hours 38 min ago:
Anybody tried Simplex? -
URI [1]: https://simplex.chat/
nadir_ishiguro wrote 21 hours 4 min ago:
Love matrix. Improving the onboarding is a great step. I've seen less
technical people have issues in that area until now.
Mostly a desktop/web user myself, hoping all that Element X work will
trickle down to us.
xyst wrote 22 hours 52 min ago:
I quickly looked at the MSCs and seems âMASâ and associated MSCs
enable OIDC/OAUTH authentication flows (basically integration with your
favorite identity provider such as Google or Apple).
I was hoping for matrix homeserver to act as an identity provider as
well to give us an alternative to big tech for âidentityâ.
I suppose I could just setup Ory or other open source IdP, but would
have been nice to have an all in one package.
Arathorn wrote 22 hours 45 min ago:
MAS can be used as an OIDC IdP, and in future MAS will be embeddable
in Synapse so you can use your homeserver as an IdP in the way you
want, all in one package.
That said, MAS is deliberately not a very featureful IdP - it's
focused on being the glue between Matrix and OIDC. If you want a
more sophisticated IdP then you'll still want to run a dedicated one.
yaky wrote 23 hours 56 min ago:
This sounds great for large and corporate servers, but a pain for small
self-hosted ones. More configuration and external dependencies. Plus
additional confusion for non-techy users on those smaller servers.
jchw wrote 23 hours 50 min ago:
I don't think this will be required for other servers any time soon,
if ever. Clients are going to have to support logging in the
oldschool way indefinitely, especially since most Matrix servers are
basically unmaintained.
t3chguy wrote 23 hours 30 min ago:
You say that, but Element X (Android & iOS) already lacks full
support for the oldschool way. It only supports certain flows
therein AIUI.
jchw wrote 23 hours 9 min ago:
Yeah, I realize that, but that's exactly why it's Element X and
not Element. Element was actually planning on dropping support
for older servers, but for ecosystem reasons they had to can that
indefinitely. I don't think Element will become Element X anytime
soon with the ecosystem in such bad shape.
oofbey wrote 1 day ago:
So Matrix is the new XMPP?
vaylian wrote 12 hours 37 min ago:
Did XMPP ever use these protocols for authentication?
Arathorn wrote 12 hours 28 min ago:
fwiw, there's a XEP for OIDC in XMPP from last year: [1] . ATproto
is also moving to it as its primary auth mechanism: [2] .
URI [1]: https://xmpp.org/extensions/xep-0493.html
URI [2]: https://github.com/bluesky-social/atproto/discussions/2656
frankzander wrote 1 day ago:
Does actually exist matrix servers for warez?
kibwen wrote 1 day ago:
Discord's ongoing enshittification may create a market opportunity for
alternatives in the near future. I'd like to think that Matrix could be
a beneficiary of that, but the common-case UX needs to be polished damn
well when the time comes if they want to capitalize.
74848732648 wrote 18 hours 1 min ago:
Eh... Discord's enshittified client is still a hundred times more
usable than Element â for all its faults, at least Discord is able
to deliver and display messages reliably ("unable to decrypt
message", anyone?). And for the more technologically oriented, client
mods do a lot to improve the Discord UX.
Element X is supposed to improve things, but it's stuck on Android
and iOS for the foreseeable future.
genewitch wrote 13 hours 44 min ago:
I haven't seen that message in literal years.
Arathorn wrote 23 hours 42 min ago:
MAS and Next Gen Auth open up the way to things like QR-login
(complete with syncing all E2EE state and verification!) which should
help enormously with common-case UX.
See [1] for a demo of it from The Matrix Conference in Sept, or [2]
showing it working in on a fresh instance of element-docker-demo at
FOSDEM 2025.
URI [1]: https://youtu.be/ZiRYdqkzjDU?t=966
URI [2]: https://youtu.be/lkCKhP1jxdk?t=1832
neilv wrote 1 day ago:
* Is all matrix.org's server-side for this open source, and able to be
self-hosted?
* Do all the Matrix clients need to be modified to support this
authentication method?
Arathorn wrote 1 day ago:
The new authentication server (MAS) is at [1] (AGPLv3) and entirely
self-hostable - e.g. [2] for the brand new official helm charts from
Element, or [3] for a very quick and dirty docker-compose setup i
threw together.
MAS provides backwards compatibility for the old Matrix auth APIs for
existing Matrix clients, so they do not need to be modified to keep
working. However, to get the most out of all the new auth features
(2FA, MFA, QR login etc. etc.) then clients will need to be upgraded
to speak OIDC natively. Element X for instance is already
OIDC-native. [4] has more details.
URI [1]: https://github.com/element-hq/matrix-authentication-service
URI [2]: https://github.com/element-hq/ess-helm
URI [3]: https://github.com/element-hq/element-docker-demo
URI [4]: https://areweoidcyet.com
cyberax wrote 1 day ago:
1. Yes. Even the public website is open source. The license is
AGPLv3: [1] 2. Yes.
URI [1]: https://github.com/element-hq/synapse
BrenBarn wrote 1 day ago:
> No more typing your password in every client youâd like to log in
to.
So. . . how will we log in? This post is heavy on vague promises of
greatness but light on concrete details of UX.
kuschku wrote 1 day ago:
If you use e.g., "Sign in with Google" today, you get redirected to
your web browser, log in, and get redirected back to the client. This
means you can use the saved passwords of your browser, and if already
logged in there, you just have to click "continue" instead of logging
in again.
With MAS, every login works like that. If you click "sign in",
instead of getting redirected to Google, you get redirected to the
website of your homeserver, where you can login and authenticate
before being redirected back to the client.
The primary benefit of using a standard OIDC flow is that your
authentication server can easily add support for passkeys, webauthn,
TOTP or captchas, without having to wait for every single client to
support these features.
While matrix.org uses MAS for this, providing the same login features
as it used to, your organization might want to use Keycloak to
connect their homeserver directly to LDAP.
mananaysiempre wrote 20 hours 39 min ago:
The downside is that you need a full browser to authenticate this
way.
palata wrote 1 day ago:
> So. . . how will we log in?
I think you will log into your server, and then the server will offer
you to give access to the client. The screenshot right below the line
you quote seems to show exactly that.
BrenBarn wrote 22 hours 23 min ago:
I guess I can believe that, but it's unclear because there's
nothing to tell me what that's a screenshot of. The icon in the
screenshot is the Element icon, which is a client, so at first
glance I figure it's a screenshot of Element. After reading your
comment I can infer that it's actually something else (a website?)
showing me the icon of the client that wants access. That makes
sense, but it's not obvious just from the screenshot.
One reason I ask about this is I always wonder how it will work for
someone writing their own client, perhaps a very basic client (or a
bot). Any answer that involves "you will click on X" doesn't apply
there. As long as there's a straightforward API based way, that's
cool. And I assume there is one here. But my experience has been
that such changes aimed at "greater security" often make things
more cumbersome for small-time developers.
But we'll see. Certainly a smoother login (and logout!) experience
for Matrix would be welcome so hopefully this will be a plus
overall.
magicalhippo wrote 20 hours 51 min ago:
The blog mentions right at the start that it's based on OAuth
2.0/OIDC, similar to how you log in to your Google account in
Thunderbird for example.
> I always wonder how it will work for someone writing their own
client, perhaps a very basic client (or a bot).
For interactive clients, it'll be the standard OAuth 2.0
Authorization Code flow[1]. For non-interactive services they say
in the proposal[2] that one uses the existing method but they
will implement the standard OAuth 2.0 Client Credentials flow[3],
which is effectively like a traditional username/password deal,
though the "password" is not the account password.
[1] [2]
URI [1]: https://learn.microsoft.com/en-us/entra/identity-platfor...
URI [2]: https://github.com/matrix-org/matrix-spec-proposals/blob...
URI [3]: https://developer.okta.com/docs/concepts/oauth-openid/#c...
halJordan wrote 1 day ago:
Read the whole blog, and it directs you further for more details. But
this blog does tell you they're moving to oidc. That means you will
get all the non password flows oidc supports.
This is a reading comprehension problem more than a blog writing
problem
jokoon wrote 1 day ago:
I set firefox to clear cookies, also using cookies to "strict"
This somehow causes a huge pain to connect to mozilla's matrix
instance, and I never understood why. This is a bit ironic since
firefox has that feature to clear cookies.
I had to reset password, and do other weird things, I can't remember
what exactly.
I hope this MAS thing fixes it.
jeroenhd wrote 14 hours 40 min ago:
Putting tracking protection to strict essentially makes Firefox
violate certain web standards. Developers aren't going to test
against that, and if they are they're probably not going to be able
to do much about the problems strict tracking protection causes.
If MAS fixes this, it'll be by accident and it'll probably break in
the future. Firefox warns against this kind of breakage if you enable
strict tracking protection in the settings. You can't have strict
tracking protection + websites doing cross-domain authentication
working.
nurettin wrote 1 day ago:
How do you prevent them from collecting "Interaction Data"?
URI [1]: https://www.mozilla.org/en-US/privacy/firefox/#bookmark-how-...
anon7000 wrote 1 day ago:
I mean, yeah, tracking prevention features basically completely break
cross-domain authentication. There are a surprising number of valid
use cases that need cross-domain auth (or make the user experience a
lot easier). While there are workarounds these days, sometimes it
does require deep changes in how auth works
jokoon wrote 1 day ago:
> There are a surprising number of valid use cases that need
cross-domain auth
I am not a web developer, but I would disagree with that.
Either web standards respect privacy or they don't, but I would not
sacrifice privacy for anything.
Firefox was right to prevent tracking, it highlights how
webstandards are just not good. I something doesn't work properly
in a firefox private window, to me it should not exist.
dwattttt wrote 1 day ago:
Authentication requires the opposite of privacy. If you don't
want to be identified, you can't restrict anything to your
identity.
johnmaguire wrote 1 day ago:
It kind of depends. See Kagi Privacy Pass ("Allows you to use
Kagi Search with Privacy Pass, which cryptographically ensures
that Kagi cannot tie that request to an account and allows for
further privacy and anonymity."):
URI [1]: https://help.kagi.com/kagi/privacy/privacy-pass.html
jeroenhd wrote 14 hours 43 min ago:
... which requires an addon to the browser, or for it to be
built in specifically for that company.
That's not something companies like Matrix can use. If you're
installing software already, why not skip the browser engine
and install a full Matrix client instead?
johnmaguire wrote 6 hours 9 min ago:
I wasn't responding directly to Matrix's use of MAS. More
generally I aimed to make the parent poster aware of a new
technology that allows for private authentication, which
they claimed was impossible.
Privacy Pass is currently being standardized by the IETF,
so we may see more widespread adoption eventually:
URI [1]: https://privacypass.github.io/
dwattttt wrote 1 hour 7 min ago:
Just to make the claim clearer: it can't matter what the
authentication mechanism is.
If a Privacy Pass token is needed for access to your
email, then redeeming the token tells the service you
(the client) can access your email. That's identified
you.
kevin_thibedeau wrote 1 day ago:
If I'm authenticating with server A. I shouldn't have to carry
ephemera from server B. A can interact with B on its own if
necessary.
Bubbling up these architectural details to the front end is a
symptom of the webdev cargo cult coming up with broken ideas
that get fossilized as the status quo.
johnmaguire wrote 1 day ago:
With OIDC, both occur: the client is redirected to the
authentication server where they directly authenticate, then
carries a token cross-domain back to the service. Finally,
the service validates the token against the auth server.
The alternative would be something where I enter my Google
username/password on random websites, and trust that they
will forward it to Google and not do anything nefarious. This
is less secure and less private.
kibwen wrote 1 day ago:
The status quo appears to involve handing over your account
password to your chosen client. That's worse than this.
cvwright wrote 1 day ago:
But you already trust your client with all the private keys and
message plaintexts for your account.
I struggle to see why I should trust it with those things but
not the account password.
tcfhgj wrote 12 hours 58 min ago:
Not necessarily, you could give restricted access to a client
lucyjojo wrote 15 hours 57 min ago:
my google account has way more power over me than whatever i
ever wrote in matrix in my life (ever, ever)
wkat4242 wrote 1 day ago:
If you don't trust your matrix client, why use it at all?
It's also a bit disheartening to see Matrix putting all that
"Log in with Google", Apple, Facebook etc so prominently on
their login page. The whole idea of decentralised services was
getting out of those walled gardens.
johnmaguire wrote 1 day ago:
Yeah, I would argue it's less about removing trust from the
client (which will ultimately get an auth token in addition
to secrets and plaintext messages) and more about allowing
for centralized authentication and authorization policies.
apples_oranges wrote 1 day ago:
So unusable for people like me who only surf in private mode
jckahn wrote 1 day ago:
Cool! Iâve recently consolidated all of my Google Chat and WhatsApp
friends onto Matrix (via Element) because itâs E2EE. Gchat isnât
and I assume that Meta has a backdoor into WhatsApp conversations. So,
those platforms canât be trusted. Signal doesnât have a web
interface, so thatâs a no-go for me. lol Telegram.
Matrix has been great for me and I recommend that everyone else use it!
methuselah_in wrote 1 hour 30 min ago:
You should not use it ! Xmpp is the answer with its few issues and
matrix requires hell of system resources as well.
anotherpaul wrote 10 hours 39 min ago:
For me the issue was contact names tbh. Is that solved? It used to be
that the contact name was set by the contact and not by me/my address
book.
crossroadsguy wrote 14 hours 30 min ago:
You mean you access all these on Matrix/Element via the bridge? Or
you actually mean you convinced all of them to ditch their chat apps
and migrate to Matrix, or at least install Element as well in
addition to the other ones? Itâs a feat if itâs the latter
without or without ditching. Is this a very privacy conscious
demographic?
ranger_danger wrote 22 hours 20 min ago:
There are ways to get web interfaces for Signal.
But I think the bigger issue is that any platform that controls the
javascript sent to you from a web page, can also backdoor/MITM/inject
malicious code at any time without you knowing.
foresto wrote 22 hours 44 min ago:
> I assume that Meta has a backdoor into WhatsApp conversations
They don't need a back door when they control the front door: the
app. End-to-end encryption doesn't protect the endpoints.
(In other words, your concern is warranted.)
pentagrama wrote 19 hours 59 min ago:
You're absolutely right. End-to-end encryption protects message
content, but WhatsApp still collects metadata, which is incredibly
valuable.
Even though they can't read your messages, they know who you talk
to, how often, when, and for how long. They also track your device
info, IP address (which can reveal your location), network details,
and app usage patterns.
And this data isnât just sitting thereâMeta uses it. For
example, if you chat with a business on WhatsApp, you might start
seeing ads for that business on Instagram or Facebook. They donât
need to read your messages when they can infer so much just from
how you use the app.
Disclaimer: Comment translated from Spanish and corrected by Chat
GPT.
ItsBob wrote 9 hours 44 min ago:
> Even though they can't read your messages
I've long wondered if this is actually true.
If I have a closed-source app and claim (and can verify!) E2EE,
surely I could still read every message from my closed-source
app, within the app itself, and you'd never know.
I've never been a mobile app developer but I've been a desktop
and web developer since the 90s so I don't know what apps can and
cannot see but in a desktop app or web app, if it's on the
screen, it's decrypted and I can put code in to read/steal it.
Am I missing something here?
floralhangnail wrote 6 hours 59 min ago:
At about 2:33:15 here, Zuckerberg somewhat alludes that Meta
can take screenshots of WhatsApp messages.
URI [1]: https://youtu.be/7k1ehaE0bdU?t=9189
robertlagrant wrote 7 hours 47 min ago:
It's true in a sense - using an iPhone or an Android phone
Apple/Google could be streaming your screen contents
constantly, so even e2ee wouldn't help.
I just don't know if that is actually true, or if meta doing
e2ee and then pinging your messages around from the app after
they're delivered is true. I've no reason to believe either is.
ranger_danger wrote 22 hours 22 min ago:
And the default/largest homeserver, matrix.org, uses cloudflare, so
all your data belongs to them as well.
foresto wrote 22 hours 17 min ago:
It is disappointing that they use Cloudflare, especially since
most Matrix metadata hasn't yet been moved to the end-to-end
encrypted channel.
(Arathorn: is e2ee metadata still on the roadmap?)
But no, not all your data is exposed. The e2ee parts, like
message content in encrypted rooms, are opaque to Cloudflare.
Arathorn wrote 21 hours 43 min ago:
yup, encrypted metadata is very much on the roadmap. [1] is one
of the more recent proposals for it.
URI [1]: https://github.com/matrix-org/matrix-spec-proposals/pu...
jcul wrote 23 hours 4 min ago:
Signal doesn't have a web interface, but being able to use a desktop
app is OK for me.
The big downside for me is not being able to use it on two devices.
All the other services, privacy concerns or not can now do this. It's
one reason why I stopped donating to / advocating for signal.
nothrabannosir wrote 17 hours 54 min ago:
Settings -> linked devices?
URI [1]: https://support.signal.org/hc/en-us/articles/360007320551-...
jcul wrote 14 hours 58 min ago:
This lets you use the desktop application and a phone at the same
time, which I use.
It doesn't allow you to use multiple phones at the same time.
nothrabannosir wrote 3 hours 58 min ago:
Thanks I didn't know that
kaiken1987 wrote 7 hours 28 min ago:
It's something I've just recently run into trying to set it up
on an Android tablet. The funny thing is they allow it on an
iPad. It'd be great if they allowed just any phone or tablet to
link to the primary device.
I'd complain but it's been deaf ears for the last 4 years to
get them to put gifs back into the desktop app.
9283409232 wrote 1 day ago:
Wasn't there a big falling out between the Matrix team and Element or
am I misremembering what happened?
Arathorn wrote 1 day ago:
Element is the company formed by the team who created Matrix to
work on Matrix, almost all of whom are still there; there is no
falling out :)
The Matrix Foundation is the non-profit set up by the Matrix team
in 2018 to keep Matrix itself independent of Element and other
Matrix vendors - to act as a steward of the protocol and a
standards body. Originally Element donated almost all of its code
on Matrix to the Foundation (e.g. Synapse, the original Matrix
server) as permissive Apache-licensed FOSS, assuming that if Matrix
was successful, folks would want to fund it.
In practice, by 2023, Matrix was very successful... but it
transpired that the vast majority of folks commercially building on
the Foundation's Apache licensed code failed to route any funding
back to the Foundation (as the hosting body) or to Element (as the
primary code contributor), despite many polite requests. As a
result, there wasn't enough $ to pay folks at Element to keep
working on the core Matrix projects as their day job. So, to keep
the lights on, Element stopped donating their work to the
Foundation, and changed license to non-permissive AGPLv3 in order
to sell AGPL-exceptions to the folks commercialising it. This has
helped the situation somewhat (although Element isn't at breakeven
yet). Meanwhile, it's left the Foundation focused on governance,
the Matrix standards process, trust & safety and hosting core
libraries like E2EE and matrix-rust-sdk.
There's no beef between the Foundation and Element over this. In a
utopia the projects would certainly have stayed as Apache licensed
code in the Foundation - but then again, other standards bodies
like W3C or XSF don't publish code these days: it's a phase that a
given protocol grows out of once third party organisations get busy
building implementations.
Disclaimer: i'm conflicted on this, being project lead/co-founder
for Matrix, and then CEO/CTO at Element.
9283409232 wrote 22 hours 41 min ago:
I understand now. Thanks for clearing that up for me.
freedomben wrote 23 hours 30 min ago:
FWIW I think AGPL is the right license choice for you. The more
experience I gain the more I lean toward AGPL for products, MIT
for libraries.
capitol_ wrote 15 hours 12 min ago:
The LGPL hits the sweet spot for libraries in my opinion.
bigstrat2003 wrote 23 hours 22 min ago:
I don't think there's anything wrong with permissive license
for a piece of software. But if you're running a business that
needs to pay developers, it's really not a good idea. Very few,
if any, people are going to donate to your project out of a
sense of duty to help you keep the lights on.
freedomben wrote 22 hours 35 min ago:
I don't disagree, but I think the bigger risk is just that
big companies who can and should throw some financial support
your way, just won't if it's permissively licensed. They've
demonstrated repeatedly that they'll just take the software
and use it, including making (sometimes substantial) money on
it, and none of that will flow back up.
ants_everywhere wrote 23 hours 44 min ago:
I say this all the time, but the point of the permissive licenses
is you're making a donation to private industry.
There are reasons to do this, for example if you believe that
private industry adopting some technology is good and you want to
make that happen.
But people keep seeming surprised by the fact that these
donations aren't reciprocated (or at least people don't seem to
plan for them to never be reciprocated). It sounds to me like the
AGPL license was more consistent with their goals.
bigstrat2003 wrote 23 hours 26 min ago:
Not quite. The point of permissive licenses is that you're
making a donation to everyone. If private industry uses your
donation fine, if not that's fine too. But it's certainly true
that if you have a problem with private industry using
something you freely gave them, permissive licenses aren't for
you.
tw04 wrote 23 hours 0 min ago:
I think we need to distinguish using and abusing. IMO a
private corporation taking the source to make a commercial
project and refusing to give anything back (whether patches,
money, or otherwise) is abusing.
When corporations utilize the code and make a good faith
effort to contribute back something, no matter how trivial,
they are using the source.
Just because itâs legal doesnât make it right and I feel
confident given the current state of the world saying that we
should start expecting more from corporations. The idea
âthey only exist to make moneyâ is how you break the
social contract.
kelnos wrote 15 hours 49 min ago:
> IMO a private corporation taking the source to make a
commercial project and refusing to give anything back
(whether patches, money, or otherwise) is abusing.
I don't agree. Releasing under a permissive license is
explicitly saying "dDo what you want with this, including
using it commercially without giving back". And if you're
saying that, you can't cry "abuse" when someone does
exactly what you told them they could do. Because that's
what you've done: the license terms explicitly say that.
"Legal" has nothing to do with it; if you want other people
to have to contribute their changes publicly, you use a
copyleft license. If you don't care, you use a permissive
license, and then there's no such thing as "abuse", as long
as people follow the letter of the license.
ants_everywhere wrote 20 hours 17 min ago:
> a private corporation taking the source to make a
commercial project and refusing to give anything back
(whether patches, money, or otherwise) is abusing.
What I'm saying is that's the point of the license. That's
why universities use the licenses (e.g. MIT, Berkeley) and
why Apache uses it. They're designed to stimulate the
private sector by moving IP from research into industry
(universities) or by industries pooling resources to make
software purchases cheaper (Apache).
I don't think it makes sense to describe using them in this
way as abusive or bad faith.
ants_everywhere wrote 23 hours 19 min ago:
If you wanted to make a donation to everyone, you'd use a
copyleft license.
The point of permissive licenses is to grant the ability to
exclude people from the enjoying the benefit of improvements.
I.e. they're not for creating public goods. They're grants
for making it easier to create excludable goods.
ranger_danger wrote 22 hours 16 min ago:
> The point of permissive licenses is to grant the ability
to exclude people from the enjoying the benefit of
improvements.
I find this comment to be incredibly disingenuous, and just
plain false.
Excluding people would only be done if someone took a
permissive license and then re-licensed it to something
more closed... you've entirely made up a malicious
assumption about what people do with the software. And
you're even assuming people ARE doing something like this
with the software.
A permissive license simply lets you do just about anything
you want with it. Some will agree this is more "free". But,
freedom TO vs freedom FROM is a common argument.
mkesper wrote 11 hours 45 min ago:
Wake up. That's what's happening to your gifts you
released under permissive licenses. Enterprises like AWS,
Apple etc. build their business on them and don't want to
give anything back.
tempfile wrote 13 hours 47 min ago:
> I find this comment to be incredibly disingenuous, and
just plain false.
I wonder if there will be any justification for this
remark :-)
> Excluding people would only be done if someone took a
permissive license and then re-licensed it to something
more closed
Yes, that is the only way they can be distinguished. If
nobody ever distributes proprietary software including
the permissively-licensed code, then it might as well be
copylefted.
> you've entirely made up a malicious assumption about
what people do with the software. And you're even
assuming people ARE doing something like this with the
software.
I think this is your point of departure with reality.
This happens constantly! Anyone who ever includes
permissively licensed code in a proprietary codebase is
denying the users of that codebase from the freedoms the
upstream developers gave them. The freedom to do this is
the freedom to withhold rights from other people. You can
choose not to care about that, if you want. But that's
what is happening.
ants_everywhere wrote 19 hours 50 min ago:
You don't need to re-license permissively licensed
software to include it in your code.
Apple, as far as I know, doesn't release the FreeBSD fork
they use in Mac OS.
Companies generally use a ton of permissively licensed
software and don't release forks of it under any license
because the entire point of the license is that you can
take the code, make modifications, and you have no
obligations to give anything back when doing so.
There was an attempt to rebrand "free software" --
meaning software focused on user freedom -- as "open
source" -- referring to software permissively licensed
for use by corporations. This was the point of the OSI.
[0]
> The âopen sourceâ label was created at a strategy
session held on February 3rd, 1998 in Palo Alto,
California, shortly after the announcement of the release
of the Netscape source code....The conferees believed the
pragmatic, business-case grounds that had motivated
Netscape to release their code illustrated a valuable way
to engage with potential software users and developers,
and convince them to create and improve source code by
participating in an engaged community. The conferees also
believed that it would be useful to have a single label
that identified this approach and distinguished it from
the philosophically- and politically-focused label
âfree software.â Brainstorming for this new label
eventually converged on the term âopen sourceâ,
originally suggested by Christine Peterson.
So literally a decision by a committee of industry folks
to play down the idea of freedoms or giving back and
focus instead on the business case.
So they killed the ethical argument that favored copyleft
licenses in favor of the business argument that favored
permissive ones.
Now people are saying "hey it's unfair that you're not
giving back." Fair enough, but that's an ethical
argument. That's what the OSI was trying to get rid of.
The OSI approach has its place. We wouldn't have Mac OS
or Google or Meta without it. But its place is allowing
industry to standardize and to reduce costs. Those
benefit consumers indirectly since we have fewer
competing standards and reduced development costs can
imply reduced end user costs. But that only works because
each company can make improvements and exclude others
from using those improvements; i.e. they can make
proprietary improvements.
[0]
URI [1]: https://opensource.org/history
ranger_danger wrote 16 hours 56 min ago:
> You don't need to re-license permissively licensed
software to include it in your code.
If the project you include it in does not use the same
license, then I think you are technically re-licensing
it.
But either way, I don't see how the rest of your
comment applies to what I said.
VladVladikoff wrote 1 day ago:
>lol Telegram
Did I miss something? what's wrong with telegram?
maqp wrote 23 hours 11 min ago:
1. It's not end-to-end encrypted by default.
2. No group chat, even a small one between close friends is
end-to-end encrypted.
3. Almost all desktop clients support no end-to-end encryption for
1:1 chats, meaning if you use the desktop client as part of your
workflow, you're forced to drop using the end-to-end encrypted
secret chats.
4. No cryptographers have ever worked in the company.
5. Horrible teething issues for the protocol:
Telegram hosted a cracking contest back in 2013. Everyone in the
industry know they are bullshit, and this was discussed back in
2013 The Fallacy of Cracking Contests (1998) | Hacker News The tldr
is, Moxie issued a counter challenge to Telegram where he presented
the same goals with already broken primitives like MD5, to break
the encryption. Telegram never proved the challenge could be won
even under those conditions. (Also again, given that Telegramâs
built in backdoor of âpeople are lazyâ exists, the cracking
contest was pointless. It doesnât matter how good the encryption
is if the adversary wears you down to hand over the keys). [1] [2]
[3] [4] [5] Also this:
URI [1]: http://unhandledexpression.com:8081/crypto/general/securit...
URI [2]: https://eprint.iacr.org/2015/1177.pdf
URI [3]: https://web.archive.org/web/20160425091011/http://www.alex...
URI [4]: https://words.filippo.io/dispatches/telegram-ecdh/
URI [5]: https://mtpsym.github.io/
URI [6]: https://blog.cryptographyengineering.com/2024/08/25/telegr...
palata wrote 1 day ago:
I don't understand why you're downvoted for this question.
What's wrong with Telegram is the privacy story. It's not
end-to-end encrypted, meaning that the server can read the content
of your messages.
I hear that Telegram has a great UX, which makes it popular. But in
terms of security... it's wanting.
maqp wrote 23 hours 15 min ago:
Telegram is a joke in professional cryptography circles
URI [1]: https://x.com/matthew_d_green/status/726428912968982529
emptysongglass wrote 15 hours 21 min ago:
You're again linking to old critiques of an old protocol no
longer in use. Can you stop doing that, please?
maqp wrote 8 hours 54 min ago:
No. I will not stop pointing out the hubris and nepotism in
the company. No real changes have been made in who's
designing security for Telegram, so their past is their
future. Incompetent people doing crap job.
emptysongglass wrote 8 hours 38 min ago:
Except to the protocol, which you continue to post aged
posts identifying vulnerabilities that have nothing to do
with the rewritten version. That is not honest presentation
of the facts.
maqp wrote 1 hour 12 min ago:
>That is not honest presentation of the facts.
They have f'd up in the past, and since they still employ
the same incompetent nepo-hirings, they will continue to
f up in the future.
Until they own their mistakes and E2EE everything, like
they should have done in the first place, I will keep
pointing out their incompetence, past and present.
You do not get to rewrite their history by telling people
to shut up.
palata wrote 22 hours 29 min ago:
To me it's just not an encrypted messaging app. I don't even
get all the discussions about it...
It's a bit like if we analysed the E2EE guarantees of email
over and over again. Every year, multitudes of people would
publish a post explaining how email is "badly encrypted". Well,
email is not E2EE, period. If you want E2EE, use a system that
has E2EE.
maqp wrote 8 hours 56 min ago:
That would be fine unless Telegram
1) Didn't say it was "Heavily encrypted" on its front page.
2) Didn't claim it was more private than WhatsApp which is
always end-to-end encrypted with Signal protocol.
3) Didn't claim secret chats were somehow adequate.
Klonoar wrote 1 day ago:
I'll tell you what's right about Telegram: I don't know how they're
the only independent app that seems to be able to produce such a
well built UI/UX for a chat application in 2025.
I maintain that someone should fork their codebase and bolt on a
different backend (Signal, Matrix, whatever). It's right there and
it's very, very good.
(Yes, I know it's not as simple as "bolt on a different backend".
You know what I mean.)
Arathorn wrote 23 hours 54 min ago:
Telegram certainly has an excellent UI/UX. On the Element side,
its quality bar has very much been the target for Element X - and
(in my biased opinion) we are getting very close, if not
exceeding it in some places. For instance, we just landed The
Event Cache in Element X and matrix-rust-sdk ( [1] - closed 2
days ago after a year of solid work), which provides seamless
offline support and local encrypted-at-rest caching of the
messages it's seen, which in turn then makes the native SwiftUI
and jetpack-compose UIs go brrrrrr.
URI [1]: https://github.com/matrix-org/matrix-rust-sdk/issues/328...
db579 wrote 12 hours 52 min ago:
Arathorn I'm a bit confused that Element pushes Element X so
much already when your own Element One service doesn't support
it yet?
Arathorn wrote 12 hours 30 min ago:
It's just because all the effort has gone into EX over the
last ~2 years, and it's a way way way better app (even if it
doesn't have threads/spaces yet).
Meanwhile, Element One will support it shortly - the missing
piece was MAS in production, which is now happening on
matrix.org as per the OP.
Klonoar wrote 22 hours 38 min ago:
> its quality bar has very much been the target for Element X
I sincerely hope you get there, but it's really hard to believe
it at the moment. You're not even at feature parity with the
app (Element vs Element X) you're replacing, and it's been out
for a bit now.
i.e, you have significant user experience related features that
keep people using Element (open graph previews, just to name
one).
palata wrote 1 day ago:
> I don't know how they're the only independent app that seems to
be able to produce such a well built UI/UX for a chat application
in 2025.
Precisely because they don't spend so much effort for privacy. If
your server can read all your messages, it's suddenly easier to
provide great features. For instance, GMail can add your next
hotel stay to your calendar automatically because it has access
to your emails. That's great UX, but poor privacy.
Klonoar wrote 1 day ago:
This is such an odd comment.
What on earth makes you think that the same engineers
responsible for fluid and smooth UI/UX are the ones whoâd
ever influence the cryptography/privacy/security? Whether or
not the chats are encrypted has zero to do with this.
Telegram has almost universally smooth scrolling, things work
well across platforms, itâs native pretty much everywhere
with low memory usage and mostly platform specific behaviors.
Signal half asses this, and Element is⦠shoddy, at best, in
comparison.
palata wrote 22 hours 34 min ago:
> What on earth makes you think that the same engineers
responsible for fluid and smooth UI/UX are the ones whoâd
ever influence the cryptography/privacy/security?
Did you even read my comment? I gave an example of how
privacy directly impacts UX: GMail couldn't automatically add
your events to your calendar if it could not read the content
of your emails. I never talked about engineers, just the
technical reality. If you don't have it, you can't read it.
That seemed absolutely obvious to me: the best UX for a car
would be one that doesn't need a source of energy, fits in my
pockets and instantly teleports me anywhere I want. Go ask
your engineers to make a car that allows that perfect UX, and
see how they react.
Telegram has no E2EE except for the secret chats. Last time I
checked, the secret chats were not synchronized between
devices (i.e. the privacy has an obvious impact on the UX).
So no, I don't think it was an odd comment. It just feels
like you don't know how it works technically.
Klonoar wrote 20 hours 45 min ago:
> Did you even read my comment?
I'm not even sure you read mine.
> It just feels like you don't know how it works
technically.
You're disregarding what I've said and trying to have a
different discussion. Please pay attention.
I am not discussing - nor do I consider it relevant to my
point - privacy/security/etc contexts for Telegram's client
side applications. Whether or not it's encrypted has zero
to do with how smooth and well built a chat UI is. I am
commenting on the frontend client side engineering and how
Telegram has, hands down, the best implementation. Other
apps need to catch up.
palata wrote 20 hours 23 min ago:
> Whether or not it's encrypted has zero to do with how
smooth and well built a chat UI is.
Ok, let's talk with concrete examples.
1. Say you open the Signal Desktop app: either you don't
get the history of the messages, or you need to wait a
fairly long time for them to arrive. With Telegram, you
get the whole history immediately. Does that count as
"smooth and unrelated to encryption" to you?
2. Say you send a message to a group on Telegram and on
Signal/Element. On Telegram you see that the message was
received noticeably faster than on the others. Does that
count as "smooth and unrelated to encryption" to you?
3. Let's talk about GIFs and stickers: I'm sure Telegram
has many more than e.g. Signal. Is that something you
consider when you say Telegram has a better
implementation and it is unrelated to the privacy
concerns?
4. Telegram has bots that enable a lot of feature. Does
that count?
You're telling me that for the stuff that isn't impacted
by privacy concerns, Telegram is better. You seem very
sure of that, and maybe that's right. But can you give
concrete examples? Because until now, what I've been
reading from you is that the UI/UX is not impacted by the
privacy, and this is obviously wrong.
So let me ask this: would you agree that at least some
UI/UX is impacted by the privacy concerns?
Klonoar wrote 17 hours 17 min ago:
Every single point that you want to try here has
nothing to do with implementing a smooth scrolling,
buttery UI/UX of a chat application. Please stop moving
the goalposts if you want to actually discuss this.
I also frankly don't even get what you're trying to say
with point 1, because Signal loads messages instantly
for me on Desktop. There's zero delay. The UI/UX of the
scrolling and chat display is the problem.
> what I've been reading from you is that the UI/UX is
not impacted by the privacy, and this is obviously
wrong
It is not obviously wrong, and you've done nothing but
attempt to loop the conversation back to some level of
privacy/encryption/etc. These things do not matter in
this conversation, full stop.
This (my thread, not the greater thread we're in) is a
design and frontend implementation discussion, not a
privacy/security discussion. If that is not clear to
you, I don't know what to say anymore.
maqp wrote 9 hours 11 min ago:
>These things do not matter in this conversation
The largest UX hit is when launching a client after
it's been powered off for a while.
Telegram uses a symmetric session key. The client can
with SINGLE AES-IGE decryption operation decrypt a
massive packet containing every message received to
every non-secret chat.
Signal uses Diffie-Hellman ratchet or SCIMP ratchet
for every received message. That means there's X25519
and AES-CBC involved for every message. It is not,
and will never be as fast as Telegram's insecure
approach.
Thus the security design will absolutely affect the
smoothness of the experience.
But Signal has blazing fast search function since
it's local only. Telegram's search functionality
freezes when you go over the server's chat history
cache limit, to try to find years old posts.
>The UI/UX of the scrolling and chat display is the
problem.
My desktop computer loads messages from my Signal
history as fast as I can scroll my mouse.
My cheap smart phone loads messages from my Signal
history as fast as I can swipe my fingers.
You can solve this with faster hardware.
palata wrote 11 hours 34 min ago:
> This (my thread, not the greater thread we're in)
Well, you're answering to my thread, if we go like
this. Where I said that one reason the UX is better
in Telegram is that they don't care about privacy.
> Every single point that you want to try here has
nothing to do with implementing a smooth scrolling,
buttery UI/UX of a chat application.
Then we fundamentally disagree on what UX means. If
it takes 2 days to receive a message because a human
has to check that it is not spam, wouldn't you say
that it's bad UX? Or is "scrolling" the only thing
that you put into "UI/UX"? Do you actually know what
UI/UX is?
> It is not obviously wrong, and you've done nothing
but attempt to loop the conversation back to some
level of privacy/encryption/etc.
Because that's my goddamn point from the beginning
on. Privacy has an impact on UX (which means "user
experience", by the way), period.
> If that is not clear to you, I don't know what to
say anymore.
Same here. You don't seem to understand how privacy
works technically, and you don't seem to understand
what UI/UX means.
maqp wrote 23 hours 23 min ago:
Unless you're extremely privileged, privacy does play a role
in every feature. There is no user experience if you're
imprisoned for speaking your mind and your government
intelligence has pwned Telegram servers.
Making a smooth app isn't that hard. Inventing the
cryptographic protocols to enable group management without
server-side control, and proving their security is the hard
part. Something Telegram's developers haven't the faintest
idea of how to do.
izacus wrote 16 hours 32 min ago:
People communicated via unencrypted phone calls and SMS and
other unencrypted mediums for decades so you might just be
massively overstating the importance of E2E message
encryption for an average person.
maqp wrote 9 hours 41 min ago:
That was the time before we lived our half of our social
lives online in group chats and social media.
My calls and texts used to be about me agreeing with my
buddies when to hang out. They weren't nearly as private
as me keeping in touch with buddies I rarely see IRL,
online.
Also, there was a period of transition. Had I known the
MSN messenger was completely unencrypted, in that
everyone, not just Microsoft, could listen in, I might
have felt my privacy violated. I sure as hell feel that
in hindsight.
palata wrote 11 hours 40 min ago:
The world was fine without Internet for most of its
history. What's your point?
kelnos wrote 15 hours 47 min ago:
The world has been changing a lot over those decades, and
the technological and surveillance capabilities of state
actors (and malicious, non-state actors, for that matter)
has increased dramatically. Not needing E2EE a few
decades ago has nothing to do with whether or not we need
it now.
est wrote 17 hours 17 min ago:
> privacy does play a role in every feature
It really depends. People discuss and communicate in public
channels like IRC or Discord.
A large chunk of chatting is shitposting with anonymous
identity.
Secure chat is only needed in some scenarios.
Klonoar wrote 22 hours 40 min ago:
> Unless you're extremely privileged, privacy does play a
role in every feature.
No, dude. Come on - you really think that plays a role in
how smooth a listview renders? Or whether it follows the
correct tab focus order? I don't think I could be more
clear about what I'm saying in my last comment. Their
client side app is incredibly smooth and well built.
Signal, Element, etc do not stack up.
> Making a smooth app isn't that hard.
Yes, it surprisingly is. Multiple chat apps in 2025 still
fail at this.
> Inventing the cryptographic protocols to enable group
management without server-side control, and proving their
security is the hard part. Something Telegram's developers
haven't the faintest idea of how to do.
This isn't even in the realm of what my point was.
maqp wrote 9 hours 28 min ago:
>Come on - you really think that plays a role in how
smooth a listview renders?
That's not a feature. Stickers is a feature. Calls are a
feature. Messages are a feature. Group chats are a
feature. Group video calls are a feature. Link thumbnails
are a feature. Forwarding messages is a feature.
>Their client side app is incredibly smooth and well
built.
Yes, and the Trojan horse was so beautiful John Oliver
would totally have hit on it.
Telegram UI is fine, I'll give you that. But it was
created at the expense of designing the app private. Move
fast yolo security isn't the justification.
They'd have to re-design the protocol from scratch to
make it E2EE by default. Hell, you can't even get feature
parity with secret chats. E.g., stickers do not work.
Signal might not have every bell and whistle like pinned
messages, but when it eventually does, I will know it's
done with proper privacy design.
I get that your point is to bore exclusively in the UI/UX
with, admiring the forest from the trees. I'm saying the
true beauty is with the ridiculously seamless and easy to
use end-to-end encryption for everything Signal provides.
Both phone app, and all desktop apps stay in sync, all
1:1 chats are E2EE and they are available on all
platforms, unlike Telegram where they're limited to phone
only. All group chats are E2EE and they're available on
all platform, unlike Telegram that doesn't have E2EE for
group chats. All chats are E2EE by default, unlike
Telegram where no chat is E2EE.
Privacy and security are integral part of every feature.
Everything else is a footgun. Arguing about how well the
footgun is polished, doesn't make it any less of a
footgun.
Signal has over time polished its secure features.
Telegram isn't in the process of securing it's polished
turd of a protocol.
athenot wrote 1 day ago:
This is not entirely true. For example, Calendar.app does the
same by locally extracting the .ics out of Mail.app without
ever sending anything to Apple.
I don't think Telegram's UX is tied to their permissive
privacy, but they do seem to start with UX then do what's
needed to support it. That does give them an edge.
(Instagram has terrible privacy and actively mines information
from chat and their UX is only passably good.)
palata wrote 22 hours 42 min ago:
> This is not entirely true.
My point is that it's generally harder to add those features
in a privacy-preserving way. GMail couldn't do it if it
couldn't read the content of the emails, period. It doesn't
mean that there is no way to have nice features in a
privacy-preserving way. I just said it's harder (sometimes
impossible).
> I don't think Telegram's UX is tied to their permissive
privacy
Not exclusively, but it is obviously a lot easier! Take a web
client: if the server has access to the data, your client can
just fetch it. If the server doesn't even know about the
existence of the group, that's harder. Why do you think only
the "secret chats" are E2EE in Telegram (and those don't
support groups)?
> then do what's needed to support it
What do they do to support privacy? They don't have E2EE
except in the secret chats! That hasn't changed in a decade!
> Instagram has terrible privacy and actively mines
information from chat and their UX is only passably good
This keeps getting further from what I said :). Of course,
it's possible to do worse than Telegram!
celsoazevedo wrote 1 day ago:
I assume it's the lack of end-to-end encryption by default on basic
features.
Good service btw, but not the best from a privacy point of view.
4cstar wrote 1 day ago:
URI [1]: https://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypte...
9991 wrote 21 hours 56 min ago:
What a bizarre explanation. Element does E2EE just fine, with
the caveat that you have to record your own encryption keys.
But if you want E2EE and backups, what would you expect?
maqp wrote 23 hours 16 min ago:
URI [1]: https://telegra.ph/Why-you-should-stop-reading-Durovs-...
celsoazevedo wrote 23 hours 25 min ago:
It's nice to see their reasoning, but the issue remains:
Telegram can read most direct messages (because almost no one
uses private chats) and everything sent in groups.
It's a good service and in some cases it can compete with
Matrix, Signal, etc, but most direct chats and all groups have
no privacy from Telegram (and anyone with access to their
servers).
SahAssar wrote 1 day ago:
Besides that there it's also them choosing to roll their own
crypto instead of using established cyphers and protocols.
emptysongglass wrote 1 day ago:
And every time someone makes this comment. MTProto 2 uses
standard crypto primitives. Besides this, do you know who else
rolled their own crypto? Moxie. You don't get to roll your own
crypto first and then weaponize this against your opponents but
that's exactly what he did along with abusing words like
"plaintext" to describe any encryption not E2EE.
maqp wrote 23 hours 17 min ago:
AES-IGE is not best practice. Neither is this [1] The
difference is Moxie isn't an amateur when it comes to
cryptographic design. Wikipedia actually lists him as a
cryptographer. The company has also employed an actual
mathematician/cryptographer, Trevor Perrin.
Meanwhile, Telegram employed the CEO's brother who's a
geometrician, which is not the same. You wouldn't hire a
dentist to perform brain surgery even though both studied
medicine.
Signal protocol's double ratchet is considered best practice
by pretty much every competent cryptographer.
MTProto's main issues are not the teething issues of the
yester-years. It's the fact every chat is sent to the server
that can then read the messages. Telegram only has E2EE in
internet debates about it's non-existent E2EE in practice.
URI [1]: https://words.filippo.io/dispatches/telegram-ecdh/
emptysongglass wrote 15 hours 47 min ago:
Are you aware the article you link to technically critiques
MTProto 1, including links to web archives of the MTProto 1
docs?
> MTProto's main issues are not the teething issues of the
yester-years. It's the fact every chat is sent to the
server that can then read the messages. Telegram only has
E2EE in internet debates about it's non-existent E2EE in
practice.
Telegram does in fact have E2EE available in the form of
Secret Chats, so that's just an incorrect statement from
you.
Regardless, that wasn't what I was rebutting. If anyone is
going to have a reasonable debate about Telegram's
problems, at least do so reasonably, without resorting to
well-worn and facile language invented by the person who
has the most to gain from its use. Moxie is not at all
innocent in any of this and I'm glad he's no longer
involved with Signal, which I use every day.
maqp wrote 9 hours 2 min ago:
>Are you aware the article you link to technically
critiques MTProto 1, including links to web archives of
the MTProto 1 docs?
Yes, but surely you realize a competent cryptographer
wouldn't have implemented a backdoor looking design in
the first place?
>Telegram does in fact have E2EE available in the form of
Secret Chats, so that's just an incorrect statement from
you.
No it's 100% correct and you just made my point for me.
1. Secret chats are not used by default, meaning most of
users don't even know about it.
2. Secret chats are not available for group chats, not
even small ones that have reasonable expectation for
privacy.
3. Secret chats are not available for desktop chats, so
you can not really use them seamlessly. I've spent six
hours in front of my computer today. My phone is 30cm
from my left hand. And I absolutely can't be arsed to
pick it up every time my friend would send me a secret
chat. Telegram's backdoor works exactly this way. They
know I'm lazy. They make it my fault. Whereas with
Signal, I can just alt-tab into the chats and reply
there.
When I said Telegram only has E2EE in internet debates,
that means people like you who love to point out it's
technically there, but who also fail to understand what
it takes for such feature to be even used on a daily
basis.
>facile language invented by the person who has the most
to gain from its use.
I've been criticizing Telegram for over a decade now. You
trying to make it sound like it's Moxie who's the devil
pulling all the strings and making my arguments for me,
makes you look like an astroturfer employed by Telegram:
URI [1]: https://tsf.telegram.org/
emptysongglass wrote 8 hours 37 min ago:
> When I said Telegram only has E2EE in internet
debates, that means people like you who love to point
out it's technically there, but who also fail to
understand what it takes for such feature to be even
used on a daily basis.
But you are being dishonest when you make an incorrect
statement like this. Don't do that.
EDIT:
> makes you look like an astroturfer employed by
Telegram: [1] I just read the linked page through: this
is a request for volunteers to answer support questions
for Telegram. How did you make the mental leap from a
request for support volunteers to recruitment ad for
astroturfers?
URI [1]: https://tsf.telegram.org/
maqp wrote 1 hour 14 min ago:
The content is lies. E.g. [1] Talks about "unique
distributed architecture" which I have debunked here
[2] When people parrot those lies, they're being
useful idiots, which Russia has used for ages [3]
Durov is trained in information warfare and
propaganda [4] He knows what he's doing.
URI [1]: https://tsf.telegram.org/manuals/e2ee-simple...
URI [2]: https://security.stackexchange.com/a/243172
URI [3]: https://en.wikipedia.org/wiki/Useful_idiot
URI [4]: https://www.nytimes.com/2014/12/03/technolog...
rlpb wrote 10 hours 22 min ago:
> Telegram does in fact have E2EE available in the form
of Secret Chats, so that's just an incorrect statement
from you.
But if you turn that on, other features turn off.
maqp wrote 9 hours 0 min ago:
Exactly. I have friends that outright refuse to use
secret chats because stickers are so important to them.
They literally have said to my face "stickers > human
right to privacy".
akimbostrawman wrote 12 hours 9 min ago:
Telegram E2EE only 1:1 that is opt-in vs Signal E2EE
everything by default.
Its clear which is an actually private chat app. Defaults
matter
jckahn wrote 1 day ago:
This is exactly it.
Steltek wrote 1 day ago:
Self-hosted Matrix with all the bridges is awesome and brings back
that Pidgin/Adium life of one chat app for all of my friends. Too bad
Apple has an uncanny ability to avoid consequences with iMessage.
nisa wrote 1 day ago:
It's wonderful that it seems work well for you but my experience in
bridging group chats with XMPP or IRC was terrible. Lost messages,
bridge crashes, puppet accounts getting randomly broken/duplicated
with discarded messages.
From the bridges I've run, only the Telegram bridge is somewhat
stable for me but it also has it's warts.
Might be different if you run a strictly personal server for 1:1
conversations but I'd say from an ux perspective the bridges idea
largely failed IMHO.
I don't think it's the fault of element/matrix it's a difficult
problem and I guess with limited resources they made a lot of
progress and made things possible that weren't before but it's not
plug and play, at least it wasn't for me.
In general I've found it's also difficult to communicate in group
chats if there are two worlds with a slightly different view
(missing reactions, some elements of the messenger are not
supported like captions, polls and so on...)
kuon wrote 23 hours 31 min ago:
While I generally agree, the slidge bridge for XMPP has been
working quite well for me, especially whatsapp, but it is really
new.
nisa wrote 23 hours 26 min ago:
> slidge bridge
Didn't knew about this one. Thanks I'm looking into it!
apetresc wrote 1 day ago:
I vaguely remember an old MSC or TWIM or something that described (the
possibility of) a new authentication mechanism whereby I could set up
either a dummy homeserver or something in .well_known that would allow
me to use my own domain but without needing to use my own homeserver
for the actual traffic. Sort of like an auth-only homeserver, if you
will.
Is that part of MAS? Was that initiative ever fully-baked? Or am I just
misremembering?
Arathorn wrote 23 hours 48 min ago:
That's .well-known based delegation, which was proposed in MSC1708 in
Nov 2017: [1] and merged into the spec in Jan 2019 (prior to Matrix
1.0 in June 2019): [2] So yes, fully-baked and part of Matrix since
1.0!
Next Gen Auth via OIDC is instead a key part of the (upcoming) Matrix
2.0 spec release - see [3] and
URI [1]: https://github.com/matrix-org/matrix-spec-proposals/blob/old...
URI [2]: https://github.com/matrix-org/matrix-spec/commit/0347e873efc...
URI [3]: https://areweoidcyet.com
URI [4]: https://github.com/matrix-org/matrix-spec-proposals/pull/386...
MartijnBraam wrote 1 day ago:
Afaik that's not related to this, that was already possible as a
domain alias. I think that feature is called a delegation if I
remember correctly.
DIR <- back to front page