3 ms·

I've been toying with the idea of a git-backed MIME email, where each thread is a repo, each message is a commit, and send/receive semantics map to push/pull op

by niftich 10y ago

I've been toying with the idea of a git-backed MIME email, where each thread is a repo, each message is a commit, and send/receive semantics map to push/pull operations. I don't work on it because I don't want to reinvent email -- a trap many have tried -- but I do want explore ways of doing content-addressed distributed messaging, and a DCVS gives you those for free.

masukomi 10y ago
that wouldn't be reinventing email. it'd be reinventing an email client, which is a great idea. HOWEVER a repo per thread seems ... not good. I'd go with a branch per thread. Maybe encode the subject in a way that git is happy with as a branch name but can be decoded to the original text or looked up from.
- niftich 10y ago
  It's a bit about the protocol, a bit about the client, I think. In worldspace, every message's direct descendants form a DAG, i.e. classic threading, so messages only know about their ancestors or successors. The "inbox" contains many independent, unrelated threads. From a client's perspective, I can see wanting to treat the inbox as a repo containing many files, each file being a thread. From a protocol perspective, the total contents and state of the parties' inboxes is not relevant (nor particularly wise to share); but you would want to push your changeset to a thread (i.e. a new message) to your recipient. A git changeset can affect many files, which is not consistent with the semantics I'd want to convey.
  - Gibbon1 10y ago
    Sometimes I'll reply to two related posts in one email. Might be that gits ability to merge threads would be a bonus vs the usual idea of representing threads as trees.
- pilooch 10y ago
  you may want a branch per mailbox so that you can merge them, fork etc
duaneb 10y ago
> push/pull operations. Exactly what I need: the opportunity to merge when trying to read my email.
capnrefsmmat 10y ago
public-inbox is a project to use git as a mailstore, so mailing list archives can be synced with a git pull. Not quite what you're describing, and they don't exactly have a detailed website, but: https://public-inbox.org/ https://public-inbox.org/

by niftich 10y ago

masukomi 10y ago

that wouldn't be reinventing email. it'd be reinventing an email client, which is a great idea. HOWEVER a repo per thread seems ... not good. I'd go with a branch per thread. Maybe encode the subject in a way that git is happy with as a branch name but can be decoded to the original text or looked up from.

niftich 10y ago
It's a bit about the protocol, a bit about the client, I think. In worldspace, every message's direct descendants form a DAG, i.e. classic threading, so messages only know about their ancestors or successors. The "inbox" contains many independent, unrelated threads. From a client's perspective, I can see wanting to treat the inbox as a repo containing many files, each file being a thread. From a protocol perspective, the total contents and state of the parties' inboxes is not relevant (nor particularly wise to share); but you would want to push your changeset to a thread (i.e. a new message) to your recipient. A git changeset can affect many files, which is not consistent with the semantics I'd want to convey.
- Gibbon1 10y ago
  Sometimes I'll reply to two related posts in one email. Might be that gits ability to merge threads would be a bonus vs the usual idea of representing threads as trees.
pilooch 10y ago
you may want a branch per mailbox so that you can merge them, fork etc

duaneb 10y ago

> push/pull operations. Exactly what I need: the opportunity to merge when trying to read my email.

capnrefsmmat 10y ago

public-inbox is a project to use git as a mailstore, so mailing list archives can be synced with a git pull. Not quite what you're describing, and they don't exactly have a detailed website, but: https://public-inbox.org/ https://public-inbox.org/