update corp details & XMPP FAQ

supporting-docs/guides/2015-08-19-faq.md

@@ -92,24 +92,40 @@ number to discover people to talk to.
 
 ##### 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?
 
-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.
 
 ##### 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
 folks all over the internet.
 
@@ -217,24 +233,24 @@ bridges as the project progresses.
 The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack,
 XMPPFramework) for IM before starting to experiment with open HTTP APIs
 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
-    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
-    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.
     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
 -   Bridging to other protocols and defragmenting existing communication
     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.)
-    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
     between clients and servers is common, especially as interoperability
     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
     questionable](http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/))
 -   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
     [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
 together.  The more federation and interoperability the better.