4 ms·

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 fre

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/msc1767/proposals/1767-extensible-events.md 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 https://github.com/pixlwave/Watch-The-Matrix - the first native Matrix client for Apple Watch. https://youtu.be/Jh9iewrBdGQ https://youtu.be/Jh9iewrBdGQ)

southerntofu 6y ago
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 6y ago
  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 6y ago
    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 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 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 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/1m4VTRqclB3JEMZBjbr4t5cvIMQUNSGxy6rYN4YtopIk/edit#heading=h.uqsgmp37gqgn https://docs.google.com/document/d/1m4VTRqclB3JEMZBjbr4t5cvI... 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 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 :)
billconan 6y ago
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 6y ago
  Why disallow Element?
  - billconan 6y ago
    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 6y ago
      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.
  - spicybright 6y ago
    Because it could be content element can't render.

southerntofu 6y ago

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 6y ago
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 6y ago
  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 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 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 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/1m4VTRqclB3JEMZBjbr4t5cvIMQUNSGxy6rYN4YtopIk/edit#heading=h.uqsgmp37gqgn https://docs.google.com/document/d/1m4VTRqclB3JEMZBjbr4t5cvI... 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 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 :)

billconan 6y ago

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 6y ago
Why disallow Element?
- billconan 6y ago
  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 6y ago
    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.
- spicybright 6y ago
  Because it could be content element can't render.