It's probably too close to FOSDOM for the Element crew to hop on the Nix bandwagon for this project, alas, but I look forward to seeing the FOSDEM effort and and ours cross-pollinate in the future!
There is one caveat: looks like "agreeing on how to do video" is not a Matrix standard; it's in the UI configuration or "widgets", which means only matrix/element combo is "properly" supported (with caveats).
Has anyone had success running video calls over Matrix without Element? Is there any movement on the protocol side?
Extending to this thread, will non-element applications have reasonable support for watching (video) fosdem?
For multiway calls, we currently embed Jitsi as a Widget - but widgets themselves are also (almost) part of the spec - they're MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236).
Element may be the only client that implements widgets so far, but we expect that to change once MSC1236 finally gets merged into the spec. Meanwhile, "ability to iframe random content into a chatroom" is a pretty useful thing, and solves the whole video conferencing thing fairly nicely.
Finally, in the longer term, we still plan to implement native voice/video conferencing in Matrix as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc235... - but for now we'd rather focus on polishing the messaging bits of Matrix.
fwiw if you use the Jitsi widget, you can share the URL to your Jitsi room with anyone and they do not need Element or Matrix to join.
The whole voice/video thing is a design problem as protocols like Matrix or XMPP are designed for non-realtime communication, while voice/video is very much realtime. You cannot possibly federate a video stream, so Matrix or XMPP can, by design, only supply the routing (i.e. connecting the people who want to participate in a realtime chat) and the participants then need to agree on some server/software combo that provides the actual video conferencing.
> fwiw if you use the Jitsi widget, you can share the URL to your Jitsi room with anyone and they do not need Element or Matrix to join.
I would like my grandma to click a green "phone" button and answer my call. I would like my grandma to be able to issue a call for me.
> and the participants then need to agree on some server/software combo that provides the actual video conferencing.
Since the button is in a very convenient place, I would expect the integration to be a bit deeper than "hope the client understands the invite"; it's tricky to make the clients without a spec.
It would have been nicer if this were documented better/more obviously, so we know what to expect if we want video calls to work across different UIs.
Sounds like XMPP all over again.
It's different, it's addressed here:
https://matrix.org/faq/#what-is-the-difference-between-matri...
We think of Matrix and XMPP as being quite different; at its core Matrix can be thought of as an eventually consistent global JSON database with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. You can use them both to build chat systems; you can use them both to build pubsub systems; each comes with different tradeoffs. Matrix has a deliberately extensive 'kitchen sink' baseline of functionality; XMPP has a deliberately minimal baseline set of functionality. If XMPP does what you need it to do, then we're genuinely happy for you! Meanwhile, rather than competing, an XMPP Bridge like Skaverat's xmpptrix beta or jfred's matrix-xmpp-bridge or Matrix.org's own purple-matrix has potential to let both environments coexist and make the most of each other's benefits.
The whole area of XMPP vs Matrix is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together. The more federation and interoperability the better.
At least XMPP is community-driven.
Every time i felt miserable on the day with less interesting talks - it is just too overcrowded and if you do not commit to a room for the whole day without leaving the room you are basically screwed. This is the only conference where i weigh my biological needs against talk topics - is topic XYZ worth suffering or should i go pee?
I think limiting the number of participants would greatly benefit FOSDEM, even if it means that some people miss it.
Or find a larger venue.
I would love to go if i knew that i would not have to suffer 90% of the time. I would also not be angry if i did not get a ticket. Maybe they should randomize who gets one instead of a first come, first serve approach to make it fair.
The goal would be to build a beautiful, private, secure, delightful instant messaging app that happens to run on Matrix, rather than building a Matrix client period. It’d still allow power users to do stuff like federation, but would by default abstract techie/Matrix concepts like homeservers, rooms, and encryption keys.
Nio is still in very early stages; the developer plans to refactor most of the app and couldn’t commit to a specific timeline or direction for it. On top of that, my vision for a client includes spinning up a (privacy-focused) business and later expanding to web, Android, and PCs.
I deinstalled the app and went back to IRC.
Personal opinion as a frequent conference attendee, I do not like pre-recorded talks.
I see why they are doing it, but I think its at the expense of conference experience.
There will be less motivation to be there to watch when you can view online later.
I found their Privacy Policy surprisingly approachable (https://matrix.org/legal/privacy-notice). Maybe because I've read through tons of policies before, but theirs seem to use very easy language, even for someone who's not a native English speaker.
Could not find any page who's title is just "Security".
Last time I checked, there was only one server really developped, not lagging behind, did that change recently ?
But also note that there is a very actively developed new (official) server implementation called Dendrite. [1]
It's somewhere between alpha and beta.
Dendrite also has some experimental support for peer to peer. [2]
[1] https://github.com/matrix-org/dendrite
[2] https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
Separately, in terms of implementations: Dendrite is usable these days, albeit beta: https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta, and meanwhile Synapse is stable. Conduit (https://conduit.rs) is making progress on federation (and works for simple use cases), and Construct (https://github.com/matrix-construct/construct) exists too.
