Support filters

[davidben]

In a way that lets the server index them.

[davidben]

Current thoughts: there's awkwardness where public messages are recip -> class -> inst, while personals are recip -> sender -> class -> inst with more weirdness for outgoing messages. One possibility for outgoing is to swap sender/recip and include a bit. Alternatively, call sender in that second chain "conversation" or something. That'll include the person you're talking to. It has the advantage that it generalizes to CCs. We'll just include all the people, serialized in some way there. To make public/personal symmetric again, public zephyrs have a conversation field, it'll just be the empty string or something.

To be indexed, probably some fields need to be duplicated into the user_messages table. But store only numbers, not strings. Maybe store a hash of the value. Or maybe have some atoms table. I like the former for its statelessness, but you could imagine people deliberately causing collisions? Is that interesting? I suppose we could add yet another secret and prepend it to the hash... sigh...

[davidben]

It's possible the right order is recip > class > sender > instance which is really weird, but given that personals sent to something other than message are used as fake ACLs, maybe not insane. recip > class > instance > sender is arguably better for ACLs, but it's terrible for conversations.

I suppose another possibility is that we don't enforce strict hierarchy and I just add a handful of indices. Or maybe index per-field and let SQL pick the best to index on? I dunno, seems optimizing the common query (hierarchical) is most sensible.

[davidben]

Okay, fake ACLs really do want the sender at the end. Sigh. Maybe two hierarchies?

• user_id > recip > class > instance
• user_id > recip > conversation > class > instance

Another possibility is to just treat -c message and other personals different in the backend.

Realistically, that second one is just

• user_id > conversation > instance

with recip and class set to constants. To start with, conversation non-empty implies recip = davidben@ATHENA.MIT.EDU.

[davidben]

Treating -c message personals special is sounding more reasonable now.