3 ms·

I feel like this is a misunderstanding. You can already self host 'Element Call' and point that to your own homeserver. The passage you're referencing just refe

I feel like this is a misunderstanding. You can already self host 'Element Call' and point that to your own homeserver. The passage you're referencing just refers to their hosted Element Call client. I'm pretty sure they're currently trying to move away from credentials-based login on 3rd-party clients to token-based authentication. I would guess they open up their hosted client when they finished implementing this new authentication scheme to avoid the doubled effort and to discourage using your homeserver credentials on "random" clients.

Arathorn 5y ago
Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create accounts on its default homeserver to get going. However, we're in the process of moving Matrix over to OIDC for auth (as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#openid-connect https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s...), at which point apps like Element Call should be able to easily hook into your existing account on your own homeserver using your existing server auth. In other words, the server will auth you, not the client. Combined with Sliding Sync (aka Sync v3) https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#sync-v3 https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s... this will then let you securely and efficiently use your existing Matrix account with apps like Element Call without it all getting bogged down with your existing chatrooms (or needlessly giving Element Call access to conversations it shouldn't care about). Finally, this is beta: the auth/reg stuff is very much placeholder - for instance, it doesn't even expose password reset, given the upcoming shift to OIDC.
- danShumway 5y ago
  > using your existing server auth Complete sidenote, but just to expand on the above, the OIDC work is particularly exciting because (at least my understanding is) it opens the door for letting people use a single Matrix account for a lot of different "stuff" on top of Matrix. There have been some interesting conversations and demos I've seen about using Matrix rooms to help with P2P sync for apps, and there are already bots on Matrix that use Matrix rooms for notifications so you don't need to send emails. But setting that stuff up is kind of challenging if you don't want to make a dedicated new user for each app or grant access to your account -- and (again, assuming my understanding is correct) I vaguely suspect that we might start to see a lot more 3rd-party apps built to integrate with Matrix once it's easier to point someone at a webapp and say, "just log in with your Matrix account, and it'll only have access to one room that's specific to this app." So imagine potentially having a collaborative app that's hyper-focused on one task, like a collaborative D&D messaging platform or some crud. And in the backend, everyone using that app uses their regular Matrix account, and under the hood it's just sending messages to a shared room -- and then as a developer you don't need to worry about handling a bunch of encryption and user accounts and all of that stuff, you might not even need a backend at all.
  - dane-pgp 5y ago
    > you might not even need a backend at all. On the basis that "the best code is no code", this could revolutionise app architecture. Imagine if instead of using blockchains, Web3 apps were backed by Matrix servers.
- mawise 5y ago
  I guess I still don't understand it. (And my apologies for coming across like I was trying to pick a fight) What does it mean that I can currently use it with my existing homeserver? The architectures for some of these federated systems can be difficult to understand, I feel like I didn't really understand what _Matrix_ was until I tried running my own homeserver.
  - jfkimmes 5y ago
    Federated systems tend to have different client and server implementations that can work in all combinations (as long as both are spec compliant). The confusing part comes into play when the client implementation is a web app that you can use to log in to any server hosted anywhere. Because of how centralized services work, we are used to a paradigm where the website you visit hosts its own backend - you cannot choose. With these federated systems, on the other hand, you can go to website element.foo.com and log in at matrix.bar.com. The blog post was saying they limited the option to log into your homeserver at matrix.bar.com (because of the reasons outlined above). This does not, however, stop you from hosting their (FOSS) app at call.bar.com and pointing it to your homeserver at matrix.bar.com

Arathorn 5y ago

Yup, the grandparent post is a misunderstanding. Basically, we want Element Call to work with a single click to a URL without requiring any account - much as Jitsi and similar do. Therefore it needs to pick a default homeserver. Currently it doesn't play well with existing Matrix accounts (as it will sync in loads of chatrooms which are irrelevant when you just want to do a call), so for expedience we just create accounts on its default homeserver to get going. However, we're in the process of moving Matrix over to OIDC for auth (as per https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#openid-connect https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s...), at which point apps like Element Call should be able to easily hook into your existing account on your own homeserver using your existing server auth. In other words, the server will auth you, not the client. Combined with Sliding Sync (aka Sync v3) https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-special-2021#sync-v3 https://matrix.org/blog/2021/12/22/the-mega-matrix-holiday-s... this will then let you securely and efficiently use your existing Matrix account with apps like Element Call without it all getting bogged down with your existing chatrooms (or needlessly giving Element Call access to conversations it shouldn't care about). Finally, this is beta: the auth/reg stuff is very much placeholder - for instance, it doesn't even expose password reset, given the upcoming shift to OIDC.

danShumway 5y ago
> using your existing server auth Complete sidenote, but just to expand on the above, the OIDC work is particularly exciting because (at least my understanding is) it opens the door for letting people use a single Matrix account for a lot of different "stuff" on top of Matrix. There have been some interesting conversations and demos I've seen about using Matrix rooms to help with P2P sync for apps, and there are already bots on Matrix that use Matrix rooms for notifications so you don't need to send emails. But setting that stuff up is kind of challenging if you don't want to make a dedicated new user for each app or grant access to your account -- and (again, assuming my understanding is correct) I vaguely suspect that we might start to see a lot more 3rd-party apps built to integrate with Matrix once it's easier to point someone at a webapp and say, "just log in with your Matrix account, and it'll only have access to one room that's specific to this app." So imagine potentially having a collaborative app that's hyper-focused on one task, like a collaborative D&D messaging platform or some crud. And in the backend, everyone using that app uses their regular Matrix account, and under the hood it's just sending messages to a shared room -- and then as a developer you don't need to worry about handling a bunch of encryption and user accounts and all of that stuff, you might not even need a backend at all.
- dane-pgp 5y ago
  > you might not even need a backend at all. On the basis that "the best code is no code", this could revolutionise app architecture. Imagine if instead of using blockchains, Web3 apps were backed by Matrix servers.
mawise 5y ago
I guess I still don't understand it. (And my apologies for coming across like I was trying to pick a fight) What does it mean that I can currently use it with my existing homeserver? The architectures for some of these federated systems can be difficult to understand, I feel like I didn't really understand what _Matrix_ was until I tried running my own homeserver.
- jfkimmes 5y ago
  Federated systems tend to have different client and server implementations that can work in all combinations (as long as both are spec compliant). The confusing part comes into play when the client implementation is a web app that you can use to log in to any server hosted anywhere. Because of how centralized services work, we are used to a paradigm where the website you visit hosts its own backend - you cannot choose. With these federated systems, on the other hand, you can go to website element.foo.com and log in at matrix.bar.com. The blog post was saying they limited the option to log into your homeserver at matrix.bar.com (because of the reasons outlined above). This does not, however, stop you from hosting their (FOSS) app at call.bar.com and pointing it to your homeserver at matrix.bar.com