4 ms·

See, this is what I keep going on about to my friends - Matrix is actually a graph syncing protocol, not an instant messaging protocol, and is a great way to bu

by robto 5y ago

See, this is what I keep going on about to my friends - Matrix is actually a graph syncing protocol, not an instant messaging protocol, and is a great way to build federated applications. I get that Element needs to focus on one use case in order to pay the bills, but there's a lot of room for applications that have barely been explored - calendars, contacts, games, social media, heck - you could build a federated gitlab-like collaboration site with truly federated data. You get multi-device sync, e2e encryption, and identity management out of the box. Thanks for putting this together, I hope there will be a gold rush as people realize how much low-hanging fruit there is!

mxuribe 5y ago
I think the very beginning the matrix project folks have used language similar to matrix being data synching...etc...But, that, the first use case is chat...but won;t end there...etc. Obviously i'm paraphrasing heavily...but once i read that, i've used similar language when i introduce matrix to friends...basically, chat/instant messenger is the first but not last/not only use case/scenario for this very cool technology.
all2 5y ago
> calendars, contacts I'm interested in this just to keep my devices sync'd up. I know Samsung/Apple/MS etc all have syncing services, but I really really want to get all my data out of their ecosystems. Just a distributed calendar app would be pretty amazing. No more iCal subscription/export/whatevers, 'just' federate the calendar between devices, and arbitrarily share it with anyone else. I have no clue where to start with building an app on these abstractions. Does anyone have any pointers? Documentation to read? High level overviews? Etc.?
- robto 5y ago
  I'd start with reading the Matrix spec, you'll want to know how the syncing protocol works, and this will give you enough familiarity that you can start playing around with curl to actually see it in action. I'd highly recommend understanding how conflict resolution works, the "Analysis of the Matrix Event GraphReplicated Data Type"[0] lays it out pretty well. Matrix-CRDT posted here should abstract most of the nitty gritty stuff, but there are no shortcuts to designing with CRDTs so familiarizing yourself with those is important. Other than that, just start playing and asking questions! The #matrix:matrix.org room is full of friendly and helpful people and I'm sure you'd be able to get answers. [0]https://arxiv.org/pdf/2011.06488.pdf https://arxiv.org/pdf/2011.06488.pdf
  - YousefED 5y ago
    The downside of building this directly on Matrix events is that I don’t think it would work offline, right? (Until p2p matrix gets more common, that is). My biased suggestion would be to see how far you get with storing the data to be synced in SyncedStore, and connecting Matrix-CRDT and y-indexeddb for local storage.
- eddieroger 5y ago
  I've been trying to fit CalDAV/CardDAV to that use case for some time, but given how the majority of any kind of useful implementation of that is in PHP (which itself is fine, it's just not my forte), or Python (Apple's server implementation), I've all but given up, setting sights on the big players you mention. But maybe there is something here. The hangup will be acting as a provider to the devices you care about - Apple has APIs in to contacts and calendars, but I wonder if they'll be as useful as native accounts would be? A fun thought experiment for a bit...
  - all2 5y ago
    I wasn't even thinking in terms of compatibility. I don't really use the event functionality in any of the calendar apps, and I don't really share my calendars. I'm more concerned about just having the information I need where I need it. I am interested in APIs, though, because those bring to light the underlying concepts people are trying to communicate. Examining APIs (I think) will show the problem domain clearly.
- chrismorgan 5y ago
  For these specific purposes, the JMAP working group at IETF is the place to start, because it’s the hub where this stuff is being incubated (though some of the work happens in other working groups). See <https://datatracker.ietf.org/wg/jmap/documents/ https://datatracker.ietf.org/wg/jmap/documents/>; the drafts JMAP for Calendars (integrating JSCalendar, published as RFC 8984 six months ago by the same group of people through the calext WG) and JSContact are particularly relevant here. Like Matrix, JMAP is commonly misunderstood, with people thinking it’s about email (it’s replacing IMAP, which is Internet Mail Access Protocol, right?), but it’s actually fundamentally an object synchronisation protocol, with the core in RFC 8620 being domain-neutral, and the email model completely separate in RFC 8621. (IMAP has also shifted a bit over time from being about mail with proper synchronisation being an unsound and secondary concern, to nailing down sound object synchronisation in extensions. But JMAP does it better.) Matrix is about decentralisation while JMAP is client-server, but you can probably reuse much or all of the underlying data models, just as JMAP for Calendars and JMAP for Contacts are establishing JMAP-independent data models models first.
  - Arathorn 5y ago
    On the Matrix side we've been keeping a close eye on JMAP, which operates in a fairly similar space to our new 'sliding sync' protocol (https://github.com/matrix-org/matrix-doc/blob/kegan/sync-v3/proposals/3575-sync.md https://github.com/matrix-org/matrix-doc/blob/kegan/sync-v3/...). We would love to adopt JSCalendar & JSContact in Matrix if they are good to go :)
    - chrismorgan 5y ago
      Good to hear! Published as RFC 8984, JSCalendar is stable; of JSContact, current draft <https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/>, <https://datatracker.ietf.org/wg/jmap/about/ https://datatracker.ietf.org/wg/jmap/about/> suggests they’re aiming to submit it for publication in about April, so there will probably be editorial and possibly minor changes only at this point.
- mab122 5y ago
  For calendar I would say: https://github.com/39aldo39/DecSync https://github.com/39aldo39/DecSync + https://syncthing.net/ https://syncthing.net/ and for sharing with someone you would run some web client on VPS talking to https://github.com/39aldo39/Radicale-DecSync https://github.com/39aldo39/Radicale-DecSync

by robto 5y ago

mxuribe 5y ago

I think the very beginning the matrix project folks have used language similar to matrix being data synching...etc...But, that, the first use case is chat...but won;t end there...etc. Obviously i'm paraphrasing heavily...but once i read that, i've used similar language when i introduce matrix to friends...basically, chat/instant messenger is the first but not last/not only use case/scenario for this very cool technology.

all2 5y ago

> calendars, contacts I'm interested in this just to keep my devices sync'd up. I know Samsung/Apple/MS etc all have syncing services, but I really really want to get all my data out of their ecosystems. Just a distributed calendar app would be pretty amazing. No more iCal subscription/export/whatevers, 'just' federate the calendar between devices, and arbitrarily share it with anyone else. I have no clue where to start with building an app on these abstractions. Does anyone have any pointers? Documentation to read? High level overviews? Etc.?

robto 5y ago
I'd start with reading the Matrix spec, you'll want to know how the syncing protocol works, and this will give you enough familiarity that you can start playing around with curl to actually see it in action. I'd highly recommend understanding how conflict resolution works, the "Analysis of the Matrix Event GraphReplicated Data Type"[0] lays it out pretty well. Matrix-CRDT posted here should abstract most of the nitty gritty stuff, but there are no shortcuts to designing with CRDTs so familiarizing yourself with those is important. Other than that, just start playing and asking questions! The #matrix:matrix.org room is full of friendly and helpful people and I'm sure you'd be able to get answers. [0]https://arxiv.org/pdf/2011.06488.pdf https://arxiv.org/pdf/2011.06488.pdf
- YousefED 5y ago
  The downside of building this directly on Matrix events is that I don’t think it would work offline, right? (Until p2p matrix gets more common, that is). My biased suggestion would be to see how far you get with storing the data to be synced in SyncedStore, and connecting Matrix-CRDT and y-indexeddb for local storage.
eddieroger 5y ago
I've been trying to fit CalDAV/CardDAV to that use case for some time, but given how the majority of any kind of useful implementation of that is in PHP (which itself is fine, it's just not my forte), or Python (Apple's server implementation), I've all but given up, setting sights on the big players you mention. But maybe there is something here. The hangup will be acting as a provider to the devices you care about - Apple has APIs in to contacts and calendars, but I wonder if they'll be as useful as native accounts would be? A fun thought experiment for a bit...
- all2 5y ago
  I wasn't even thinking in terms of compatibility. I don't really use the event functionality in any of the calendar apps, and I don't really share my calendars. I'm more concerned about just having the information I need where I need it. I am interested in APIs, though, because those bring to light the underlying concepts people are trying to communicate. Examining APIs (I think) will show the problem domain clearly.
chrismorgan 5y ago
For these specific purposes, the JMAP working group at IETF is the place to start, because it’s the hub where this stuff is being incubated (though some of the work happens in other working groups). See <https://datatracker.ietf.org/wg/jmap/documents/ https://datatracker.ietf.org/wg/jmap/documents/>; the drafts JMAP for Calendars (integrating JSCalendar, published as RFC 8984 six months ago by the same group of people through the calext WG) and JSContact are particularly relevant here. Like Matrix, JMAP is commonly misunderstood, with people thinking it’s about email (it’s replacing IMAP, which is Internet Mail Access Protocol, right?), but it’s actually fundamentally an object synchronisation protocol, with the core in RFC 8620 being domain-neutral, and the email model completely separate in RFC 8621. (IMAP has also shifted a bit over time from being about mail with proper synchronisation being an unsound and secondary concern, to nailing down sound object synchronisation in extensions. But JMAP does it better.) Matrix is about decentralisation while JMAP is client-server, but you can probably reuse much or all of the underlying data models, just as JMAP for Calendars and JMAP for Contacts are establishing JMAP-independent data models models first.
- Arathorn 5y ago
  On the Matrix side we've been keeping a close eye on JMAP, which operates in a fairly similar space to our new 'sliding sync' protocol (https://github.com/matrix-org/matrix-doc/blob/kegan/sync-v3/proposals/3575-sync.md https://github.com/matrix-org/matrix-doc/blob/kegan/sync-v3/...). We would love to adopt JSCalendar & JSContact in Matrix if they are good to go :)
  - chrismorgan 5y ago
    Good to hear! Published as RFC 8984, JSCalendar is stable; of JSContact, current draft <https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/>, <https://datatracker.ietf.org/wg/jmap/about/ https://datatracker.ietf.org/wg/jmap/about/> suggests they’re aiming to submit it for publication in about April, so there will probably be editorial and possibly minor changes only at this point.
mab122 5y ago
For calendar I would say: https://github.com/39aldo39/DecSync https://github.com/39aldo39/DecSync + https://syncthing.net/ https://syncthing.net/ and for sharing with someone you would run some web client on VPS talking to https://github.com/39aldo39/Radicale-DecSync https://github.com/39aldo39/Radicale-DecSync