It's insanely cool to see a non-IM use case built out on top of Matrix appearing (almost) out of the blue - congratulations :)
The implementation currently freestyles a bit on the event format for the messages, which is somewhat our fault on the Matrix team for running horrifically late on MSC1767 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc176...) which proposes how to do rich custom event formats (e.g. blog posts) which are still renderable and visible to more generic Matrix clients (e.g. Element). As a result, if you join a Hummingbard conversation via another Matrix client currently you can't see all the messages (or vice versa). However am hoping that Hummingbard might be a trailblazer for actually exercising MSC1767 in the wild and knocking it into shape, which would hugely benefit the whole Matrix ecosystem :)
In terms of licenses, it depend on how you want the project to be used. If you want folks to run it for personal use as a decentralised social network, I'd personally go GPLv3 or AGPLv3. If you want commercial folks to be able to build on it too, then Apache is probably the best bet. copyleft + proprietary dual licensing is another option, but means you'd need any contributors to agree to the dual licensing (could be tricky), and could be seen as not being in the spirit of the GPL. that said, IANAL, YMMV.
Hello, i'm not a contributor to the matrix ecosystem but i'm happy to see discussion of the vocabulary used and MSC1767. Is there a working group talking about vocabulary or interop with other federated networks (ActivityPub/XMPP)? I'm a contributor to joinjabber.org which is not a software project but a community-oriented one, and we'd like to showcase and help improve interop with Matrix, but for now due to bugs in bifrost a bot relaying messages is the best we can do.
Specifically about hummingbard and/or MSC1767, have you considered borrowing/extending ActivityStreams 2.0 vocabulary? It's based on JSON-LD (proper schemas make it easier to test implementation) and could be extended to support matrix Actors/Services.
There's already a bunch of really cool stuff being developed on ActivityPub (lemmy/funkwhale/peertube/mobilizon) and Jabber/XMPP (movim/libervia). It would be great to achieve interoperability between all those.
Arathorn seems to always be on HN but chose to leave this question unanswered. I wonder why?
I'll hazard a guess: New Vector LLC sees it is in their financial interest that they own the only functional implementations of the Matrix protocol and what it can interact with, so there's no interest in federation with the wider Fediverse and other protocols.
What does it look like to actually write a program ontop of Matrix? Eg i have a key value store that i'd like to use Matrix (or IPFS/etc) for the P2P layer. Is it a lot like IRC channels that you connect to, pushing data into them and getting data out from other clients in the same channel?
Ie is it a series of messages? Or is it something more advanced; with built in conflict resolution or other P2P-y features?
Hey, I can't comment about Matrix's P2P implementation as I haven't played with it yet. It's still a heavy work-in-progress I believe.
Regular Matrix is pretty straight-forward - you join rooms and send events. Events get propagated to all participating/federated servers that are in the room. You watch for incoming events.
The Matrix devs should be able to say more about their P2P implementation. :)
I can't tell what language Hummingbard is coded in. Hint?
GPL with targeted relaxations is usually a good way to start. You can always relax the license more later if you exercise the foresight to get contributors to allow relaxations per your judgment; and, don't rely on any strict GPL dependencies. Being GPL but not able to use GPL libraries is a funny position to get into, but that's our world.
> is it a series of messages? Or is it something more advanced; with built in conflict resolution or other P2P-y features?
From the client's perspective, matrix is just a basic stream of events (like XMPP). The magic happens on the server side where a room is replicated across servers and conflict-resolution voodoo is applied. That's also why synapse server is really really resource-intensive (gigabytes of RAM) compared to equivalent-in-features (apart from decentralized rooms) XMPP/ActivityPub servers ; dendrite is fairing better but i haven't benchmarked it yet.
this isn’t really correct (but is a common misunderstanding). from the client’s perspective, a matrix room is a persistent timeline of events which you can long-poll (/sync) and navigate forwards and backwards (/messages). Events can also update key/value state associated with a room (eg that room’s name, topic, avatar, membership, or any other metadata), which you query via /state. This is not a stream of events like XMPP but a replicated DAG of events.
Synapse’s RAM usage is a) way better these days, b) not due primarily to the merge resolution algorithm (state res), but due to slapping in-memory caches everywhere rather than being smarter on the db schema. Dendrite does 5x better by being smarter in the schema, and Conduit looks to be even better via cunning use of using key/value dbs for persistence (sled).
No but in the next couple days. I actually wanted to go with the strictest copyleft license, but there was a discussion earlier about dual-licensing, which left me quite confused. I'm not very knowledgeable at all in these matters and am taking my time to decide.
It's really a matter of strategy. Do you want the protocol/vocabulary to be used everywhere, but in closed-source implementations with a free/libre ecosystem constantly lagging behind? Or do you want something that will be less friendly to governments and multinationals but will be part of a striving lesser/non-profit ecosystem?
XMPP/Matrix went the first way. Matrix ecosystem has one reference client/server with really good features but hardware requirements that place it out of ordinary folks' reach. Similarly, XMPP has some really good apps built on top (eg. Whatsapp) but the free-software clients (not servers) are lagging behind, though catching up quickly in the past years.
ActivityPub ecosystem went the other way with AGPL everywhere (Mastodon/Epicyon/Funkwhale/Peertube/PixelFed/Funkwhale/Mobilizon/WriteFreely/Lemmy/Plume) with the notable of bookwyrm who has the Anticapitalist Software license. As a consequence of the ecosystem tailoring to users/non-profits/cooperatives not corporations/governments, it's blooming into this amazing and friendly ecosystem where everybody contributes and interoperates. Hell, who would have thought three years ago selfhosting federated/p2p livestreaming video would be become so easy as Peertube?
Personally i'm more on Jabber/XMPP's side (i contribute to joinjabber.org project, and use Jabbber/XMPP daily) mostly for technical reasons (AP/matrix haven't yet caught up with XMPP in many regards) but in my view adopting loose licensing is what almost killed the XMPP ecosystem all these years ago when it had the exact same promises as matrix does today: one universal federated protocol to bridge to all others.
could someone share the run downs of open source and the various licenses in a laymen's term way? i never felt quite comfortable when why's of certain licenses.
If you go with copy-left you automatically disqualify some major institutions from using your software. Especially for a community based project, there may be institutions that want to make proprietary extensions so it can integrate better with their existing infrastructure.
Generally I think MIT is a good default and you should only use a different license if you have a strong case for why MIT doesn't make sense for your project.
Also, since you're asking users to type in their matrix password onto https://hummingbard.com, it would be nice to have some understanding of why (even though you can host anything anyway).
I haven't gotten into the Matrix scene yet, but just want to say I think this is really cool and I can imagine there is a niche that would really appreciate it.
Hey, it's not integrated into a server, it just requires Dendrite (a beta Matrix server implementation) for certain features (like threading) that have not been implemented in the reference server (Synapse).
This sounds terrific, and I can’t wait to try it out! I’m looking for an easy to use alternative to Facebook Groups.
With an app (sometime soon, I hope), there’s a better chance of getting more users to adopt it. I’ve been waiting for Pixelfed (decentralized alternative to Instagram) to release an iOS app, but it still hasn’t seen the light of the day.
Readit News
The implementation currently freestyles a bit on the event format for the messages, which is somewhat our fault on the Matrix team for running horrifically late on MSC1767 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc176...) which proposes how to do rich custom event formats (e.g. blog posts) which are still renderable and visible to more generic Matrix clients (e.g. Element). As a result, if you join a Hummingbard conversation via another Matrix client currently you can't see all the messages (or vice versa). However am hoping that Hummingbard might be a trailblazer for actually exercising MSC1767 in the wild and knocking it into shape, which would hugely benefit the whole Matrix ecosystem :)
In terms of licenses, it depend on how you want the project to be used. If you want folks to run it for personal use as a decentralised social network, I'd personally go GPLv3 or AGPLv3. If you want commercial folks to be able to build on it too, then Apache is probably the best bet. copyleft + proprietary dual licensing is another option, but means you'd need any contributors to agree to the dual licensing (could be tricky), and could be seen as not being in the spirit of the GPL. that said, IANAL, YMMV.
(At the risk of going somewhat off topic, another exciting Matrix client also appeared today: https://github.com/pixlwave/Watch-The-Matrix - the first native Matrix client for Apple Watch. https://youtu.be/Jh9iewrBdGQ)
Specifically about hummingbard and/or MSC1767, have you considered borrowing/extending ActivityStreams 2.0 vocabulary? It's based on JSON-LD (proper schemas make it easier to test implementation) and could be extended to support matrix Actors/Services.
There's already a bunch of really cool stuff being developed on ActivityPub (lemmy/funkwhale/peertube/mobilizon) and Jabber/XMPP (movim/libervia). It would be great to achieve interoperability between all those.
I'll hazard a guess: New Vector LLC sees it is in their financial interest that they own the only functional implementations of the Matrix protocol and what it can interact with, so there's no interest in federation with the wider Fediverse and other protocols.
Now Arathorn, come tell me why I'm wrong
Ie is it a series of messages? Or is it something more advanced; with built in conflict resolution or other P2P-y features?
Regular Matrix is pretty straight-forward - you join rooms and send events. Events get propagated to all participating/federated servers that are in the room. You watch for incoming events.
The Matrix devs should be able to say more about their P2P implementation. :)
I can't tell what language Hummingbard is coded in. Hint?
GPL with targeted relaxations is usually a good way to start. You can always relax the license more later if you exercise the foresight to get contributors to allow relaxations per your judgment; and, don't rely on any strict GPL dependencies. Being GPL but not able to use GPL libraries is a funny position to get into, but that's our world.
From the client's perspective, matrix is just a basic stream of events (like XMPP). The magic happens on the server side where a room is replicated across servers and conflict-resolution voodoo is applied. That's also why synapse server is really really resource-intensive (gigabytes of RAM) compared to equivalent-in-features (apart from decentralized rooms) XMPP/ActivityPub servers ; dendrite is fairing better but i haven't benchmarked it yet.
Synapse’s RAM usage is a) way better these days, b) not due primarily to the merge resolution algorithm (state res), but due to slapping in-memory caches everywhere rather than being smarter on the db schema. Dendrite does 5x better by being smarter in the schema, and Conduit looks to be even better via cunning use of using key/value dbs for persistence (sled).
XMPP/Matrix went the first way. Matrix ecosystem has one reference client/server with really good features but hardware requirements that place it out of ordinary folks' reach. Similarly, XMPP has some really good apps built on top (eg. Whatsapp) but the free-software clients (not servers) are lagging behind, though catching up quickly in the past years.
ActivityPub ecosystem went the other way with AGPL everywhere (Mastodon/Epicyon/Funkwhale/Peertube/PixelFed/Funkwhale/Mobilizon/WriteFreely/Lemmy/Plume) with the notable of bookwyrm who has the Anticapitalist Software license. As a consequence of the ecosystem tailoring to users/non-profits/cooperatives not corporations/governments, it's blooming into this amazing and friendly ecosystem where everybody contributes and interoperates. Hell, who would have thought three years ago selfhosting federated/p2p livestreaming video would be become so easy as Peertube?
Personally i'm more on Jabber/XMPP's side (i contribute to joinjabber.org project, and use Jabbber/XMPP daily) mostly for technical reasons (AP/matrix haven't yet caught up with XMPP in many regards) but in my view adopting loose licensing is what almost killed the XMPP ecosystem all these years ago when it had the exact same promises as matrix does today: one universal federated protocol to bridge to all others.
Generally I think MIT is a good default and you should only use a different license if you have a strong case for why MIT doesn't make sense for your project.
> Hummingbard’s code will be available as soon as I am able to decide which license works best for us.
As for the password, Hummingbard needs it for the same reason that a server-hosted webmail client like Roundcube needs your email password to log in.
For more signups, it would be great to support social logins. That has been implemented in some version of Matrix, but I’m not sure if it’s in Dendrite yet: https://github.com/vector-im/element-android/issues/2452
With an app (sometime soon, I hope), there’s a better chance of getting more users to adopt it. I’ve been waiting for Pixelfed (decentralized alternative to Instagram) to release an iOS app, but it still hasn’t seen the light of the day.