* Making Pinecone resilient to attacks. It's working well for clear weather scenarios, but we need to properly try to break it and get it audited. Need to test it at scale too.
* Improving Dendrite so that it's more stable and efficient clientside
* Metadata-protecting store-and-forward, so that clients can pass messages to each other without needing to be online at the same time. You can cheat and run a serverside P2P node to relay, but then it stacks up metadata - whereas half the point of P2P is reduce Matrix's metadata footprint.
* Account portability. Currently each node is a separate account; need to support the same logical account being replicated over multiple nodes.
* Better than full-mesh routing. This should be pretty easy as we can just follow Pinecone's topology to route traffic between nodes rather than having each node try to simultaneously post to every other node in a given room.
You can get testflight & APK builds from #p2p:matrix.org if you want to experiment.
AFAIK, there are 6 server implementations of Matrix protocol: Synapse (Python), Dendrite (Go), Conduit (Rust), Construct/Charybdis (C++), Plasma (Elixir), Jeon (Java). Are there any more that I have missed? Which ones other than Synapse are most mature? An unbiased comparison post (that remains updated) would be really useful.
A second question is: are the APIs between a homeserver and the frontend defined and standardized? I've noticed this in the ActivityPub ecosystem where it is usually very easy to use one frontend with another backend. Are matrix servers also written in the same way?
Yes the matrix spec is all standardized. You can use any client with any homeserver.
Matrix's API surface is big, and servers deliberately handle all the heavy lifting in order to make clients trivial to write, so writing servers is not trivial. But Dendrite & Conduit are both very usable and making good progress right now.
And yes, the APIs are all standardised (while also constantly evolving) as per https://spec.matrix.org :)
* This might be a worthy tool for simulating aspects of scale: http://imunes.net/
* I assume power usage is a non-trivial concern (looks like yall have been worried about this too). I've tried my fairshare of P2P apps on mobile, and this can be a dealbreaker for many folks. I assume this will be something that has to be dialed in on mobile clients (and probably provides options to the user). I'm sure there are many trade-offs to consider, and I'm hoping logical accounts will provide significant advantages here. Are you feeling confident this will succeed?
* The Store-and-Forward problem looks like a really big deal. Defaulting to friends (for those folks who are lucky to have them) or a chosen subset to proxy seems reasonable. Having the clear ability to pick out who we trust here (including volunteer networks) seems solid (I'm a huge fan of Retroshare's F2F concept). I take it that, ideally, with logical accounts and excellent NAT traversal (also a sore spot usually), one's own cloud of machines will obviate some of the desire to run anything in a datacenter (and even perhaps make friends a fallback). I'm excited to see Dendrite and Conduit grow!
* As part of that portability, at least to my ideal, I'd be able to join my network from scratch using a password hashing algorithm for the private key, as otherwise I may be reliant upon secondary networks to move keys. This is often one of the first applications I want to install on a system to bootstrap myself in.
* Pinecone's Topology looks like a good idea (Yggdrasil is dope too). That metadata problem may still raise its ugly head here. Do you predict the use of onion routing, at least with Tor and i2p, will be relatively easy to integrate in addition? Do you foresee Matrix enabling its own onion routing some day?
* If you had to take a wild guess at the first stable moon landing, when do you think that might occur? Do you think 5-years may be acceptable?
Power usage is looking pretty positive so far; as long as we route the Matrix traffic over the routing topology rather than going full-mesh it should minimise radio usage (the main battery suck, other than screen).
For store-and-forward, honestly using P2P Nodes as intermediaries is an okay approach other than exposing metadata to them. Our plan in the longer term is to switch to loopix-style mixnets to obfuscate the store and forwarding, a la nym.
In terms of joining the network by deriving a private key from a passphrase... yup, that could be cute, although slightly terrifying in terms of the risk of weak passphrases :)
We're hoping to get the P2P network stable in the coming year (although we were also aiming for this year originally :P)