[HN Gopher] Show HN: Hummingbard - decentralized communities bui...
___________________________________________________________________
Show HN: Hummingbard - decentralized communities built on Matrix
Author : SubGenius
Score : 196 points
Date : 2021-02-26 17:50 UTC (5 hours ago)
(HTM) web link (hummingbard.com)
(TXT) w3m dump (hummingbard.com)
| ohyeshedid wrote:
| This is a really interesting idea. When you decide on a license,
| I'll be diving into this for sure.
| adkadskhj wrote:
| 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?
| SubGenius wrote:
| 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. :)
| southerntofu wrote:
| > 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.
| Arathorn wrote:
| 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).
| adkadskhj wrote:
| For the key-value storage, would it make sense to use it as
| a "large" KV database?
|
| Eg, for sake of simplicity, imagine you're storing Git in
| Matrix (similar to what i'm doing, if i use Matrix). I've
| got two primary concepts:
|
| 1. A mutable set of pointers.
|
| 2. A series of key values, where the keys are content
| addresses, and the values are a byte array.
|
| My initial assumption would be to use the messages to post
| all newly created blocks and changes of pointers. Eg, Send
| a message with a new content address and the bytes. Send a
| message with a new address for a pointer.
|
| For a Git-like to work in that model, it just needs to
| slurp up any messages in the datastream. Making sure to
| also slurp in old messages properly that maybe are out of
| order (ie, reconnecting after being offline for a while).
| But being a Git-like, it's a fairly simple model.
|
| With that said, perhaps the metadata storage in Matrix
| would better suite some of this? I just imagine Matrix
| isn't intended to host TiBs of `/state` metadata.
|
| Thoughts?
| CitrusFruits wrote:
| 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.
| ampdepolymerase wrote:
| Is this open source? Deplatforming is a very big concern for a
| proprietary platform.
| SubGenius wrote:
| 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.
| southerntofu wrote:
| 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/Mobil
| izon/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.
| feanaro wrote:
| > Matrix ecosystem has one reference client/server with
| really good features but hardware requirements that place
| it out of ordinary folks' reach.
|
| Define ordinary folks, please. Matrix isn't really _that_
| resource intensive for a small homeserver between family
| and friends.
| Taek wrote:
| 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.
| randmeerkat wrote:
| MIT licensing is also how entities like Amazon get away
| with pillaging OSS.
|
| I think you have a real product here and would caution you
| against releasing the source code.
|
| If you do want to open source it, I highly recommend GPLv2
| or 3.
| dariusj18 wrote:
| In this case, wouldn't it be great if the big dogs picked
| up the tech and ran with it?
| feanaro wrote:
| The same way Google and Facebook picked up XMPP and ran
| with it?
| sodality2 wrote:
| Remember that they failed though.
| etiam wrote:
| Looks dead enough to me in practice?
| dariusj18 wrote:
| From my perspective that was a good thing. I still use
| Pidgin as my google hangouts client.
| feanaro wrote:
| It was a good thing until they ruined it after increasing
| their strangle on the userbase. It would be sad to see
| the existing big guys get involved in Matrix to make it
| popular, only to corrupt it and close it off once it's
| served its purpose.
| southerntofu wrote:
| > If you do want to open source it, I highly recommend
| GPLv2 or 3.
|
| This is solid advice for client software. However for
| software to run on the server side, AGPL providers better
| protections to ensure further developments remain free
| (copyleft).
| really3452 wrote:
| As the author you can always re-release the code under MIT
| but once it's released under MIT corporations can whole
| sale rip your work off for their own profit. If you keep it
| closed source or GPL it then you maintain some breathing
| room from another company just swooping in and monetizing
| you code for their profit.
| danbolt wrote:
| > If you go with copy-left you automatically disqualify
| some major institutions from using your software.
|
| For what it's worth, I think there's reasoning to consider
| it on a project-by-project basis. An example might be how
| XMPP more or less became a bunch of walled-garden forks for
| various messengers like Google Chat and Facebook. I think
| Linux thrived with the GPLv2's copyleft being a "sweet
| spot" for them.
| xster wrote:
| 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).
| SubGenius wrote:
| Hey, my post clearly says to either sign up or use a
| throwaway Matrix account, and even asks to avoid using your
| main Matrix account.
|
| 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.
| svieira wrote:
| Buried towards the bottom of the post:
|
| > Hummingbard's code will be available as soon as I am able to
| decide which license works best for us.
| Arathorn wrote:
| 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.
|
| (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)
| southerntofu wrote:
| 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.
| hhvn wrote:
| Is there any reason this has to be integrated into a server
| instead of just rendering things like it does currently, from
| regular rooms?
| SubGenius wrote:
| 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).
| zaik wrote:
| How does this compare to movim.eu (based on XMPP)?
| kixiQu wrote:
| This is very cool! If you end up writing about what the developer
| experience on top of Matrix is like I'd also be curious about
| that.
___________________________________________________________________
(page generated 2021-02-26 23:00 UTC)