update corp details & XMPP FAQ

pull/977/head
Matthew Hodgson 7 years ago
parent 883767a905
commit 414ef70592

@ -92,24 +92,40 @@ number to discover people to talk to.
##### What kind of company is Matrix.org? ##### What kind of company is Matrix.org?
Matrix is an open initiative which acts as a neutral custodian of the Matrix.org is an open initiative which acts as a neutral and independent custodian
Matrix standard. It's not actually incorporated anywhere at the moment of the Matrix standard. As of Sept 2017 we are finally in the process of incorporating
but we are looking at the best legal structure for the future (and as it as a dedicated non-profit entity (most likely a limited by guarantee UK private company
of October 2015 we have hopefully found one). Whatever the legal called the Matrix.org Foundation).
structure, we are committed to keeping the Matrix project open.
##### Who is funding Matrix.org? ##### Who is funding Matrix.org?
Most of the current core contributors to Matrix work at Matrix.org is currently (Sept 2017) funded by the community, through a
[Amdocs](http://amdocs.com), who have kindly given us permission to work combination of community support (via
on Matrix as an independent non-profit initiative. Other contributors [Patreon](https://patreon.com/matrixdotorg),
[Liberapay](https://liberapay.org/matrixdotorg), Bitcoin and Ethereum),
corporate sponsorship, and grant funding. Current Elliptic-level supporters on
Patreon and corporate sponsors can be found on our [supporters
page](https://matrix.org/blog/supporters). If you would like to support the core
Matrix team as a member of the community, please visit our
[Patreon](https://patreon.com/matrixdotorg) or
[Liberapay](https://liberapay.org/matrixdotorg) pages, or you can send us
Bitcoin at 1LxowEgsquZ3UPZ68wHf8v2MDZw82dVmAE or Ethereum at ETH
0xA5f9a4f9E024F6D727f7afdA9257e22329A97485. If you would like to sponsor the
team as a corporation, or are interested in paying for prioritised or custom
development, please [get in touch](mailto:matthew@matrix.org).
For the first three years of Matrix's development (2014-2017), most of the core
contributors worked for [Amdocs](https://www.amdocs.com), who paid for them to
work fulltime on Matrix. In July 2017, Amdocs considered the project to be
sufficiently successful that it could now self-support and so stopped funding.
The majority of the core team is now employed by New Vector, an independent company
set up to hire the team and support Matrix's development. Other contributors
are funded by their own employers or donate their own time to the project. are funded by their own employers or donate their own time to the project.
##### Who is building Matrix? ##### Who is building Matrix?
The core team is ~10 people with extensive experience in building custom The core team is ~12 people with extensive experience in building custom
VoIP and Messaging apps for mobile network operators. Most of us have VoIP and Messaging apps for mobile network operators. Most of us work for New Vector,
day jobs at [Amdocs](http://amdocs.com) or [OpenMarket](http://openmarket.com),
but there are an increasing number of contributors from other companies and but there are an increasing number of contributors from other companies and
folks all over the internet. folks all over the internet.
@ -217,24 +233,24 @@ bridges as the project progresses.
The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack, The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack,
XMPPFramework) for IM before starting to experiment with open HTTP APIs XMPPFramework) for IM before starting to experiment with open HTTP APIs
as an alternative in around 2012. The main issues with XMPP that as an alternative in around 2012. The main issues with XMPP that
drove us in this direction were: drove us in this direction **as of 2012** were:
- Not particularly web-friendly - you can't easily speak XMPP from a - Not particularly web-friendly - you can't easily speak XMPP from a
web browser. (N.B. Nowadays you have options like XMPP-FTW and web browser. *N.B. Nowadays you have options like XMPP-FTW and
Stanza.io that help loads with letting browsers talk XMPP). Stanza.io that help loads with letting browsers talk XMPP*
- Single logical server per MUC is a single point of control and - Single logical server per MUC is a single point of control and
availability. (MUCs can be distributed over multiple physical availability. *MUCs can be distributed over multiple physical
servers, but they still sit behind a single logical JID and domain. servers, but they still sit behind a single logical JID and domain.
FMUC improves this with a similar approach to Matrix, but as of Oct FMUC improves this with a similar approach to Matrix, but as of Oct
2015 there are no open source implementations.) 2015 there are no open source implementations. The MIX XMPP extension
also aims to address this limitation*.
- History synchronisation is very much a second class citizen feature - History synchronisation is very much a second class citizen feature
- Bridging to other protocols and defragmenting existing communication - Bridging to other protocols and defragmenting existing communication
apps and networks is very much a second class citizen feature apps and networks is very much a second class citizen feature
- Stanzas aren't framed or reliably delivered without extensions. (See - Stanzas aren't framed or reliably delivered without extensions. *See
[wiki.xmpp.org](http://wiki.xmpp.org/web/Myths#Myth_Four:_XMPP_is_unreliable_without_a_bunch_of_extensions.) [wiki.xmpp.org](http://wiki.xmpp.org/web/Myths#Myth_Four:_XMPP_is_unreliable_without_a_bunch_of_extensions.)
for an XMPP take on this) for an XMPP take on this*
- Multiple device support is limited. (Apparently Carbons and MAM help - Multiple device support is limited. *Carbons and MAM aim to resolve this*
with this)
- Baseline feature set is so minimal that fragmentation of features - Baseline feature set is so minimal that fragmentation of features
between clients and servers is common, especially as interoperability between clients and servers is common, especially as interoperability
profiles for features have fallen behind (as of July 2015) profiles for features have fallen behind (as of July 2015)
@ -242,13 +258,13 @@ drove us in this direction were:
count X.509 certs, which [are count X.509 certs, which [are
questionable](http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/)) questionable](http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/))
- Not particularly well designed for mobile use cases: push; - Not particularly well designed for mobile use cases: push;
bandwidth-efficient transports. (Since the time of writing a [Push bandwidth-efficient transports. *Since the time of writing a [Push
XEP has appeared](http://xmpp.org/extensions/xep-0357.html), and XEP has appeared](http://xmpp.org/extensions/xep-0357.html), and
[wiki.xmpp.org](http://wiki.xmpp.org/web/Myths#Myth_Three:_It.27s_too_bandwidth-inefficient_for_mobile.) [wiki.xmpp.org](http://wiki.xmpp.org/web/Myths#Myth_Three:_It.27s_too_bandwidth-inefficient_for_mobile.)
claims that XMPP runs "fine" over a 9600bps + 30s latency link.) states that XMPP is usable over a 9600bps + 30s latency link.*
The whole subject of XMPP vs Matrix seems to bring out the worst in This said, the whole area of XMPP vs Matrix is quite subjective.
people. Rather than fighting over which open interoperable communication Rather than fighting over which open interoperable communication
standard works the best, we should just collaborate and bridge everything standard works the best, we should just collaborate and bridge everything
together. The more federation and interoperability the better. together. The more federation and interoperability the better.

Loading…
Cancel
Save