HN user

oddvar

211 karma

[ my public key: https://keybase.io/oddvar; my proof: https://keybase.io/oddvar/sigs/8rTUlcioTV22VGDfzPmJ2SaTwOXMmnUOBh79EJ7e2us ]

Posts0
Comments28
View on HN
No posts found.

What if there was a free, interoperable protocol that could connect anything to anything?

That's what we are trying to achieve with Matrix (https://matrix.org) - making apps connect either natively or via gateways/bridges.

We already have bridges to IRC, Slack, and libpurple! Ideally we would connect all services to each other, but obvs we can only do so for those who offer an API.

In Matrix, you can set up a WebRTC call with any Matrix-user, and the user can take the call in whatever Matrix-client he wants. We already have open source clients for web, iOS and Android!

Thanks! Vector (http://vector.im) has had a lot of UI/UX focus - but the nice thing with Matrix is that it enables you to pick the type of app/client that you like - and whether that's a web client like Vector, a terminal client like weechat (http://matrix.org/blog/project/weechat-plugin/), a mobile app, or even a different service like IRC - that's entirely up to you!

Check out http://matrix.org/blog/try-matrix-now/ for a list of clients/apps that support Matrix!

hi - it's not normally this slow - and the slightly increased traffic due to the comment above shouldn't have caused it. We're looking into it!

and thanks for trying it out :)

edit: AFAIK we've not been featured on product hunt

but there are alternatives!

https://matrix.org is an open standard defining a communication protocol. The goal is to have an open ecosystem where any app can talk to any other app. You can talk to Matrix either natively - or via a bridge. We already have written bridges to IRC, Slack, XMPP and libpurple - if you visit #matrix on freenode you are also talking in the #matrix:matrix.org (https://vector.im/beta/#/room/#matrix:matrix.org) room in Matrix (and vice versa).

You can even connect to Matrix via your IRC client via http://pto.im/

Matrix is decentralised, you can run your own server (clone our server or write your own) and servers will create federated networks on a need-to-know per-room basis (see http://matrix.org/#about).

Matrix is free software, all our code is Apache2 licensed, you can clone it (https://github.com/matrix-org) and use as-it, modify it - or write your own client client and/or server (http://matrix.org/docs/spec/r0.0.1/)!

disclaimer: I work for Matrix.org!

I agree. We're building https://matrix.org (a free and open communication protocol) and we've realised that until we have a client with better UX than proprietary offerings, people just won't switch.

We hope that a Matrix-enabled client (https://vector.im is looking promising) will get the UI/UX right - and thus actually offer an open and free solution where you can run your own server (should you choose) and own and control your own data!

Hey, have you looked at https://matrix.org? If you build on us, you don't have to fear ever being cut off - we're completely open source and free! We do also have a slack-bridge, and we're building more bridges - our goal is interoperability rather than isolated silos!

IRC is great, and I'm sure it could be great for non-geeks too! When we started working on Matrix (matrix.org) we based a lot of the messaging/chat side of things on the features we like (and the ones we miss!) from IRC, and now we have a bridge to our IRC channels which means you can chat to Matrix-users from irssi or whatever - or you can use the webbrowser or android/ios matrix client and still keep an eye on IRC.

Auto-backfill is really nice. And being able to send rich content is something we kind of take for granted these days.

(disclaimer: I work on Matrix.org)

Hi Duncan - another option is matrix.org - we're similar to XMPP although at the same time different: Matrix is effectively an eventually consistent DB with open federation and pubsub semantics - it's all about synchronising state, whereas XMPP is about federated messaging - sending stanzas around rather than synchronising conversation history.

In fact in Matrix we don't even have the concept of sending a message over federation - the only thing you can do is to synchronise the history datastructure.

We don't see Matrix as undermining XMPP: if you want decentralised conversation history then use Matrix. If you want fast stateless message passing, use XMPP. Infact, we're building an XMPP<->Matrix bridge, so that XMPP can federate with Matrix - so it's not like we're fragmenting things further. The point for Matrix is to try to defragment all the different protocols out there.

OK let me try to explain it better: let's say we have a conversation between 3 friends who are all running their own homeservers to connect to matrix. All three servers will keep a copy of the conversation, and if one server goes down and reconnects, the two other servers can update it with the messages that went on while it was down.

If friend 1 and 2 have a separate conversation in a different room, only their two servers will keep a copy of the conversation history. If friend 3 joins this room, his server will receive the current history from the other servers (there's a limit for efficiency but you can explicitly get all the history via pagination).

There is another option - matrix.org is a new open standard for real-time communication (with encryption) in an open, federated ecosystem.

That means you can run your own server and encrypt your own data, and the encrypted data can still be sent to other servers in the federation.

To your point about open source, if something like this can take off it needs to be fully open and transparent, without fees or central data ownership - which is why matrix.org is a non-profit organisation and the standard open source.

(disclaimer: I'm involved with matrix.org)

The capability to get conversation history over several servers. In Matrix the conversation history is stored by all servers involved in the discussion, and thus it can be retrieved if your own server temporarily goes down. It will also be accessible from all your Matrix-compliant clients, whether they are web or mobile clients.

(edit: disclaimer: I'm also involved with matrix.org)

That would be one way to do it :)

Problems with SIP:

* There are so multiple SIP standards (e.g. rfc 3261 vs rfc 2543)

* It doesn't support NAT (unless you do rfc5626, rfc5627 and ICE)

* Its support for ICE doesn't work well with webrtc which dynamically generates candidates

* SIP's reliability is bad unless you implement rfc3262

* We want to do messaging really well - and SIP's support for that is rather basic

edit: finally, I do agree with your "yet another standard" comment! (as per the xkcd in http://matrix.org/blog/2014/09/03/hello-world/)

Given that XMPP hasn't taken off as it could have done - and the fact that each large IM or VoIP application seems to end up writing their own version (and putting that in their own walled garden) - we think a new, well-defined open standard, together with open source reference server and client codebases can be the catalyst to create an interoperable and federated "message transport" solution for a multitude of services!

as per the FAQ: The initial goal of Matrix is to fix the fragmentation of VoIP and IM, but Matrix’s real potential and ultimate mission is to be a new and truly open ecosystem on the Internet enabling services, devices and people to easily communicate with each other.

I'd say IM and VoIP would be the obvious common cases, but Matrix can and will be used to solve all kinds of problems!

The main issues with XMPP that drove us in this direction were:

* Not particularly web-friendly – you can’t easily speak XMPP from a web browser.

* Single server per MUC is a single point of control and availability

* History synchronisation is very much a second class citizen feature

* Stanzas aren’t framed or reliably delivered (without extensions)

* Multiple device support is limited

* Baseline feature set is so minimal that good user experience cannot be guaranteed

* No strong identity system

* Not particularly well designed for mobile use cases (push; bandwidth-efficient transports)

disclaimer: I'm involved with this project!