So there were some problems with the protocol from before that end up getting resolved by tweaking the mindset. As I’ve tried to say a few times now, there are only “entities” and “events”, and I kept getting caught up on the “3 vs. 2” logical ideas (Users and Pods both being entities but the distinguishing made sense for the time), but we don’t have to anymore because I realized… a “Pod” isn’t anything. It’s just a location for us to drop a bunch of serialized, encrypted, events and then have “entities” claw that back to life as they rip over the stream.

Anyway, with that in mind we can just eliminate the concept of a “Pod” altogether and understand that instead a “Pod” is just the namespace for that particular stream. It’s just a prefix.

syntax = "proto3";
package app;

service Application {
    rpc Signup(SignupParams) returns (Token) {}
    rpc Signin(SigninParams) returns (Token) {}

    rpc UpdateSelf(UpdateSelfParams) returns (User) {}
    rpc DeleteSelf(DeleteSelfParams) returns (Empty) {}
    
    rpc GetMessagesFromPod(GetMessagesFromPodParams) returns (Messages) {}
    rpc PutMessageToPods(PutMessageToPodsParams) returns (Message) {}
    rpc DeleteMessages(DeleteMessagesParams) returns (Messages) {}
}

message Empty {}

// AUTH

message Token {
    string token = 1;
}

message SignupParams {
    string username = 1; // signed
    string password = 2;

    bytes pub_signing_key = 3;
    bytes signature = 4;
}

message SigninParams {
    string username = 1; // signed
    string password = 2;

    bytes signature = 3;
}

// ENTITY

message User {
    string username = 1;
    bytes pub_signing_key = 2;

    bytes key_set = 4;
    bytes nonce = 5;
    bytes encrypted_content = 9;
}

message UpdateSelfParams {
    bytes key_sets = 2;
    bytes nonce = 3;
    bytes encrypted_content = 4;
}

message DeleteSelfParams {
    string password = 2;
}

// EVENT

message Messages {
    repeated Message messages = 1;
}

message Message {
    string id = 1;
    bytes nonce = 2;
    bytes key_set = 3;
    bytes encrypted_content = 4;
}

// INTERACTION

message GetMessagesFromPodParams {
    string pod_id = 1;
    uint32 max_count = 2;
    
    uint64 since = 3; 
    repeated bytes public_keys = 4;
}


message PutMessageToPodsParams {
    message IdToKeySets {
        string pod_id = 1;
        bytes key_sets = 2;
    }

    repeated IdToKeySets id_to_key_sets = 1;

    bytes nonce = 2;
    bytes encrypted_content = 3;
}

message DeleteMessagesParams {
    repeated string ids = 1; // signed
    bytes signatures = 2;
}

Conclusion

Gonna be less restrictive on who can be in what pod. I think this will decrease the ways that we could monetize (I had thought maybe you could pay per pod? but just doesn’t feel like we should gate participation in a discussion, beyond block-lists, with $). Maybe we could do the whole “pay for storage, pay for compute” thing, like we do with cloud providers, and people just think that it is what it is and we all get on board with privacy coming at a cost, and then like, they also could charge for access to their content within a given group or something. Then you gotta get some kinda peer-to-peer payment option and that had been mentioned earlier too with the building of client apps.

Anyway, pods aren’t exclusive, they’re imaginary, they’re ghosts and they’re really just “topics” on a message queue now (as sad and pathetic as that is).