[HN Gopher] Show HN: Hummingbard - decentralized communities bui...
___________________________________________________________________
Show HN: Hummingbard - decentralized communities built on Matrix
Author : SubGenius
Score : 363 points
Date : 2021-02-26 17:50 UTC (1 days ago)
(HTM) web link (hummingbard.com)
(TXT) w3m dump (hummingbard.com)
| erlend_sh wrote:
| This is an essential extension of Matrix, great job!
|
| 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
| 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. :)
| ncmncm wrote:
| Hey, there's no prob, with Bob!
|
| 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.
| grey_earthling wrote:
| A reminder: for software designed to be used via the
| network, the GPL behaves like a permissive licence --
| you're not distributing binaries to users, so the
| requirement to publish source code isn't triggered.
|
| If you want forks accessed via the network to publish
| source code, use the AGPL, otherwise you may as well just
| use the MIT licence.
| 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?
| Arathorn wrote:
| Yeah, Matrix isn't a good fit yet for freeform large KV
| storage. For instance, there isn't a good way to paginate
| state yet: you can query values by a given key, or a
| given type, but not paginate. Also, each KV pair gets fed
| into the merge resolution algorithm, which can start to
| get sluggish with more than ~100K events (although it's
| got way better in Synapse since
| https://github.com/matrix-
| org/synapse/blob/master/docs/auth_... landed a few weeks
| ago).
|
| In the longer term we'd (well, I'd) love to make it work
| well with freeform KV data (or object graphs! you gotta
| store your VR scene graphs in Matrix, after all) and act
| like some kind of crazy global zero-trust CouchDB or
| Cassandra. But right now the KV state is meant to be for
| relatively simple freeform metadata about a room.
| southerntofu wrote:
| > In the longer term we'd (well, I'd) love to make it
| work well with freeform KV data
|
| That would be great for a decentralized forge based on
| matrix. This is an area where i think matrix
| decentralized rooms would shine, as they would
| effectively prevent DMCA takedowns for software projects.
| southerntofu wrote:
| > This is not a stream of events like XMPP but a replicated
| DAG of events.
|
| Thanks for the clarification. My point was that building
| something client-side for matrix is pretty straightforward,
| in case that was not clear.
|
| > not due primarily to the merge resolution algorithm
| (state res), but due to slapping in-memory caches
|
| Good to know. conduit doesn't quite look to be ready, but
| would you recommend using dendrite in production to serve a
| few users? i guess i'll give it a go
| Arathorn wrote:
| Dendrite is still beta but is usable (as hummingbard is
| demonstrating). There are some missing features which
| make it less useful day to day currently, like push
| notifs, and currently the Dendrite team is off doing P2P
| and low bandwidth Matrix work. It'll be back soon enough
| though.
| 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.
| newscracker wrote:
| 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.
| dantyti wrote:
| love it! this is the straw that finally got me to read up on
| Matrix. Will definitely start running my own server this year.
| 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.
| jzer0cool wrote:
| 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.
| kanjus wrote:
| These might be helpful to you and Hummingbard's creator:
|
| https://choosealicense.com/licenses/ provides a concise
| rundown of a few common ones
|
| https://www.gnu.org/licenses/license-list.en.html: a more
| detailed list
|
| https://github.com/plibither8/licensed: a CLI tool to help
| choose licenses (we're on HN).
| 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.
| 3np wrote:
| We're < 5 users on my synapse server running on a modern
| mid-range 6c/12t CPU. 4GB DDR4-2966 RAM dedicated to
| synapse. It has a separate decently fast postgres cluster
| for the db. Only 2000 rooms.
|
| It's frustratingly slow and heavy, regardless of client.
| Arathorn wrote:
| Perf problems arise with Synapse if those 2000 rooms
| include massive ones with tens or hundreds of thousands
| of users (or other state events). The number of local
| users is fairly irrelevant.
|
| If you grep the logs for state-res you will probably see
| that some room is consistently chewing resources (these
| days we explicitly log the worst offenders); easiest bet
| is to ask your users to leave that room or use the
| shutdown api to remove it from the server.
|
| Otherwise, it may be that there's so much data flying
| around due to the busy rooms that the in-memory caches
| are blowing out. This makes everything slow down as the
| DB gets hammered, and unintuitively uses more RAM as slow
| requests stack up. The solution is to increase the cache
| factor, much as you would on an overloaded db. We're
| currently looking at autotuning caches do you don't have
| to do this manually.
|
| If it's still slow, then there's probably a bug or other
| weirdness (ancient Python?) - my personal server has
| about 5 users on a 4 core cpu and uses about 2GB of RAM
| without a dedicated DB node and is in thousands of rooms
| (including busy ones).
|
| (Also it hopefully goes without saying that all bets are
| off if you aren't on the latest Synapse release - we are
| constantly landing improvements currently; eg the auth
| chain cover algorithm eliminates most of the known perf
| edge cases on state resolution).
| 3np wrote:
| Thanks for the pointers - on latest release with Python
| 3.8 and roughly 2~5 of those rooms are on the larger ends
| of the spectrum.
|
| Sounds like I should tune some caches then - I have
| memory to spare if it turns out to make a difference.
|
| BTW, I just noticed there is an option to add a Redis -
| would that be a significant improvement compared to just
| using the process caching?
| Arathorn wrote:
| So you'll want to try dialling up the overall cache
| factor a bit.
|
| Redis is only useful if you split the server into
| multiple worker processes, which you shouldn't need to at
| that size (and even then, doesn't provide shared caching
| yet, although there's a PR in flight for it - we
| currently just use redis as a pubsub mechanism between
| the workers).
|
| Highly recommend hooking up prometheus and grafana if you
| haven't already, as it will likely show a smoking gun of
| whatever the failure mode is.
|
| Are the logs stacking up with slow state-res warnings?
| Stuff like: 2021-02-25 23:15:26,408 -
| synapse.state.metrics - 705 - DEBUG - None - 1 biggest
| rooms for state-res by CPU time:
| ['!YynUnYHpqlHuoTAjsp:matrix.org (34.6265s)']
| 2021-02-25 23:15:26,411 - synapse.state.metrics - 705 -
| DEBUG - None - 1 biggest rooms for state-res by DB time:
| ['!YynUnYHpqlHuoTAjsp:matrix.org (148.6s)']
| southerntofu wrote:
| Well client-side there seems to be progress but to my
| knowledge so far Riot was the only feature-complete
| client, and it's REALLY heavy/slow especially on high-
| latency links. Loading app.element.io before logging in
| is already 9MB. Also element responsiveness in general is
| really tied to latency and is therefore not pleasant to
| use on bad connections and/or Tor.
|
| Server-side, many smaller hosting coops went into matrix
| but later dropped it because of synapse using too much
| resources. I know individual selfhosters who were really
| sad to drop it because their raspberry pi didn't have
| enough RAM (512MB-1GB) for selfhosting synapse.
|
| However someone said in another thread that synapse
| resource usage is really better these days. Would you
| recommend it on such low-end hardware? (ActivityPub/XMPP
| servers fare really well in such conditions)
| ncmncm wrote:
| Also, element-desktop 1.7.21 SEGFAULTs during startup on
| my Debian machine. Would rather it didn't. Wow:
| $ ldd `which element-desktop` | wc -l 102
| Arathorn wrote:
| please file a bug report if you haven't already so we can
| hunt the problem; i'm unaware of this.
| CameronNemo wrote:
| Is it not just an electron? I would see if you can anbox
| the APK. Although the stock Debian kernel is not up to
| task. Need to turn the Android knobs. Binder and ashmem.
| smichel17 wrote:
| Hey, what smaller hosting coops are out there? I'm a
| member at hcoop.net, wondering what else like us is out
| there.
| feanaro wrote:
| The thing that eats the most resources is joining very
| large, public Matrix rooms. If you don't do this, it
| won't be resource heavy.
|
| I've heard of people running Synapse on a RPi 3 (see http
| s://old.reddit.com/r/selfhosted/comments/g9h6au/matrixri.
| .. for instance) for such use cases. If you want to chat
| in large 1000+ member rooms, it probably won't be enough.
| However, even for such a use case, you don't need
| anything that is out of reach of a common person, just a
| few gigabytes of RAM. In general, it's hard to make it go
| over 3 GiB. My server hovers around 2 GiB and I'm in many
| large rooms, including the beast that is Matrix HQ.
|
| So I would agree that Synapse is not usable on RPi-level
| hardware in _all_ use cases, but you can definitely run
| it on such hardware for _some_ use cases. Dendrite is
| also maturing really quickly and will be less resource
| hungry.
| psychoslave wrote:
| >less friendly to governments
|
| Definitely not: https://matrix.org/blog/2018/04/26/matrix-
| and-riot-confirmed...
|
| And having worked for the last 6 months in a French
| governmental agency, Tchap[1] is the only internal instant
| messaging solution I was made aware of. Most people still
| had an email+phone centred work-flow however.
|
| [1] https://www.tchap.gouv.fr/
| 3np wrote:
| GP is saying XMPP/Matrix went in the "more friendly to
| governments" direction, due to the dual licensing.
| eeZah7Ux wrote:
| > less friendly to governments
|
| Citation needed. The European Union Public License is
| copyleft and it's literally written by governmental bodies.
| southerntofu wrote:
| Yes but not all governments are the EU, and not all
| governments of the EU publish anything, even loss so
| under copyleft.
|
| Even a government like france which is involved in strong
| open-washing campaign has serious Microsoft ties behind
| the scenes (education & military mostly) and despite all
| the promises for 100% OPEN, keeps on introducing closed-
| source algorithm which are paid for with millions of
| euros of public money and whose results are very sketchy
| to say the least (i'm looking at you ParcourSup).
|
| So, when i said "less friendly to governments", i did not
| mean from a legal perspective. I meant AGPL is only one
| expression of a global approach to software development
| that is focused on user empowerment. Such software is
| usually less concerned with problems of big organizations
| (including governments), and less likely to try and
| reinforce governmental control (which is something most
| governments are looking for in a product). Does that make
| sense?
| psychoslave wrote:
| Well, both the mere citizen and government are users who
| like to have as much control on their digital tools. The
| difference seems to be more on who this power is expected
| to be exerted on. Individual themselves in the former,
| the national population for the later.
| 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).
| hda2 wrote:
| While the AGPL would ensure that developments remain
| free, it will also ensure that most entities (commercial
| and non-commercial) that need tight integration would not
| touch it with a 10 foot poll.
|
| The choice of license really depends on what the OP aims
| to achieve with his software.
| 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.
| hda2 wrote:
| On the other hand, if you accept contributions while
| under a strict license like the AGPL but then decide to
| go MIT, you'll have to ask each contributor to relicense
| his or her work or remove that work altogether.
|
| OP, if you see your project switching licenses down the
| road, you might as well look into CLAs, a whole other can
| of worms, or just stick with the least restrictive
| license that achieves your goals. I'd personally use
| LGPLv3.
| 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.
| tomjen3 wrote:
| No you don't. Some institutions are stupid and have
| bureaucratic rules, but unless you need them it should not
| be your concern.
|
| I don't know of any copy left license that prevents you
| from making JSON API calls from any source you want, so you
| can integrate something like matrix easily enough.
| eeZah7Ux wrote:
| > you automatically disqualify some major institutions
|
| No: it's their choice, and if they choose not to use GPL
| software it is evidence that they do not care about user
| and developer software freedom. And that they don't want to
| contribute back.
|
| Also, "some major institutions" is very unclear. Google is
| ok with GPLv2 but not with GPLv3. Apple has restrictions on
| their app store.
|
| Both companies are extremely unlikely to support
| decentralized communities anyways - they outright compete
| against them.
| webmaven 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._
|
| This is still possible with GPL (and the AGPL, for that
| matter) by granting an exemption to the license for third-
| party extension software that is in the form of a plugin
| using a specific API.
|
| It is worth noting that depending on the details of your
| (and the plugin's) implementation, such an exemption may
| not even be required.
|
| This is probably a good place to start digging in to the
| topic: https://www.gnu.org/licenses/gpl-
| faq.html#GPLAndPlugins
|
| But before anyone starts down this rabbit hole (the legal,
| social, and technical details of which I personally find
| fascinating, but YMMV), a maintainer should instead think
| about the things they want to allow, the things they want
| to forbid, and the things they want to be able to charge
| for. Also, which of the aforementioned things they want to
| provide strong guarantees for in the event of a change in
| ownership and/or a fork (eg. MySQL/Oracle,
| OpenOffice/LibreOffice, etc.).
|
| But whatever the preferences are for a particular project,
| there almost certainly is a way to set those boundaries
| using a FLOSS license, and it is probably possible while
| using the GPL (but if you're leaning toward 'allow
| individuals and mega corps to do whatever they want', there
| isn't much sense in using the GPL as a starting point),
| though it is possible you might need a few additional tools
| for some scenarios (requiring a Contributor License
| Agreement or even copyright assignment for contributions,
| license exemptions for specific APIs, splitting out some
| shared libraries and releasing those under a different-but-
| compatible license, dual licensing, separate licensing for
| non-code assets, a nonprofit foundation, compatibility
| testing and associated badging & trademarks, etc.).
|
| Anyway, there are a lot of tools available, and most of
| them can be grabbed when and as they're needed, if they
| ever are.
|
| So, start with what you want in terms of permissions and
| boundaries, then ask for advice on enabling/enforcing that
| structure with a FLOSS license, and it can probably be done
| without too much complexity (assuming that it isn't
| incompatible with FLOSS, like 'This software cannot be used
| by the military or to support the creation of WMDs').
| 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)
| billconan wrote:
| If I create a non-IM use case, can I limit the type of clients
| that are allowed to connect to the server? For example,
| disallow Element?
| popinman322 wrote:
| Why disallow Element?
| spicybright wrote:
| Because it could be content element can't render.
| billconan wrote:
| because the use case is very different from an IM, for
| example a video game.
|
| what will you see if you open it in Element?
| Arathorn wrote:
| You can't limit the clients which connect; it's an open
| protocol. If the data being stored in the rooms can't be
| represented as text messages then you will see empty
| rooms - but the point of MSC1767 is to try to ensure that
| you do see a relatively meaningful representation of
| custom structured data even in a plaintext Matrix client.
| For instance a video game could have a bunch of KV state
| events in the room representing game objects. With
| MSC1767 they could have simple fallback representations
| visible in a generic Matrix client (eg "chair" or "door")
| or more sophisticated HTML representations (eg an html
| table showing you that object's name and spatial
| coordinates and velocities). Or a more sophisticated but
| generic matrix client might be able to map out generic 3D
| or 2D scenes without actually understanding the game
| specifics. Basically, think of the generic Matrix clients
| as acting as a debugger console which at least gives you
| some way to interact with a room - and lets generic
| bots/bridges interact for the simpler generic use cases
| like IM and VoIP.
| 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.
| newvectorsux wrote:
| 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.
|
| Now Arathorn, come tell me why I'm wrong
| Arathorn wrote:
| _sigh_
|
| The reason I skipped over this was because the author
| seemed to be pushing an agenda elsewhere in the thread
| ("Matrix is like XMPP but with a heavier server":
| https://news.ycombinator.com/item?id=26279816, and "Matrix
| has one reference client/server with really good features
| but hardware requirements that place it out of ordinary
| folks' reach.":
| https://news.ycombinator.com/item?id=26279780) which made
| me wonder whether answering all their posts was going to be
| a good use of time. In practice, the thread hasn't exploded
| into a XMPP v. Matrix holy war, so it looks like my
| concerns were ill-founded.
|
| To actually answer the question from the post in question:
|
| > Is there a working group talking about vocabulary or
| interop with other federated networks (ActivityPub/XMPP)?
|
| No, there isn't a formal WG - instead there are a set of
| informal conversations between the 3 projects. I lurk on
| xsf@muc.xmpp.org and standards@xmpp.org in case interop
| discussions come up; I also hang around various cross-
| project rooms where Gargron and Christopher Allen Lemmer
| and others are active on the AP side. As a result, cross-
| project initiatives sometimes pop up - for instance Matrix
| supported Mastodon in adding E2EE at
| https://github.com/tootsuite/mastodon/pull/13820, and we've
| also tried to work with XMPP on using Olm for E2EE as an
| alternative to libsignalprotocol in OMEMO.
|
| In terms of content vocabulary specifically: we researched
| JSON-LD a bunch when working on MSC1767 (back when it was
| MSC1225) - the notes predate us using GFM for MSCs and are
| archived at https://docs.google.com/document/d/1m4VTRqclB3J
| EMZBjbr4t5cvI...
|
| In practice, I'm not convinced there's a huge amount of
| value of standardising on the same vocabulary though -
| whether that's MIME, JSON-LD, RDF-flavoured JSON-LD, IPLD,
| rich XMPP stanzas, etc - as long as there's a way to map
| between them. Given you need to map the protocol layer in
| general when bridging protocols, why not map the content
| format too? That said, if folks have solved the problem
| elsewhere satisfactorily, then we'd have no problem with
| piggybacking on it on Matrix (just as others have
| piggybacked on Matrix's E2EE).
|
| In terms of the parent's comment:
|
| > 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.
|
| No, my priority is trying to make the wider Matrix
| ecosystem as diverse and healthy as possible, including
| bridging nicely other protocols into Matrix. The more
| different projects building on Matrix (e.g. hummingbard)
| the more potential in the network and protocol for everyone
| involved. A rising tide lifts all ships, as it were. My
| dream for Matrix is to become the realtime communication
| layer of the open Web, and for there to be as many
| different parties building on it as do the open Web today.
| If we pull that off, then Element (formerly known as New
| Vector) would hopefully benefit from it as much as everyone
| else - much as 3Com benefited from creating Ethernet and
| bootstrapping that industry alongside DEC, Intel, Xerox and
| others.
|
| But it would be _UTTERLY STUPID_ for Element to privilege
| itself over other contributors to Matrix, and would
| effectively self-sabotage the open ecosystem, thus killing
| the main thing which could make Element successful in the
| long term. Hence the huge amount of effort and $ that we
| put into setting up The Matrix.org Foundation
| (https://matrix.org/foundation) as a neutral independent
| guardian of the protocol, and protect it from anyone
| commercially building on Matrix... including Element/New
| Vector.
|
| Sorry you think we suck though :)
| jarbus wrote:
| Wow, this is really cool! My biggest issue with Matrix right now
| is performance, does it use Synapse as a backend and if so are
| there plans to move to dendrite in the future?
| likeafox wrote:
| > Hummingbard is dependent on Dendrite, the second-generation
| Matrix homeserver written in Go. Features like spaces and
| threading have only been implemented on Dendrite. Note that it
| is a forked repo with a temporary patch for paginating threads.
|
| Pretty interesting. I was putting a little effort to get a
| Dendrite homeserver running a month or two ago and it was non-
| trivial at that time for me - but evidently the author feels
| it's stable enough to run an experimental project like this.
| 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-27 23:01 UTC)