Initial commit

This commit is contained in:
2026-05-15 21:42:15 -07:00
commit ba35808572
8 changed files with 965 additions and 0 deletions
+194
View File
@@ -0,0 +1,194 @@
use uuid::Uuid;
use crate::message::{MessageId,Message};
use crate::state::{StateType,StateValue,StatePath,StatePermission,StatePermissionKey};
use crate::{RoomId,Group,Role,User,GroupPower};
use serde::{Deserialize, Serialize};
//StatePath [String]
//octal is fine for now
//maybe do ACL late???
//StatePermissions (u8,u8,u8)
//RoomId [i64]
#[derive(Serialize,Deserialize,Clone,Debug)]
pub struct TaggedClientMessage {
message: ClientMessage,
#[serde(with = "serde_bytes")]
signature: Box<[u8]>,
user: User
}
#[derive(Serialize,Deserialize,Clone,Debug)]
pub struct SignedClientMessage {
message: ClientMessage,
// Should I enforce this being a ecdsa signature?
#[serde(with = "serde_bytes")]
signature: Box<[u8]>
}
#[derive(Serialize,Deserialize,Clone,Debug)]
pub enum ClientMessage {
Auth{
username: String,
password: String
},
// Maybe ask for email too? Or a potential invite code
UserCreate {
username: String,
password: String,
},
// Used to require accounts to complete some kind of challenge. Simplest
// is giving a password/invite code to create an account or join a room
ChallengeAnswer {
response: String
},
// TODO I still dont have key management commands
// Should it be one message type or mutiple?
Message {
body: String,
},
// Private message/invite mechanism
MessagePost {
body: String,
user: User
},
// Replace the body of the message with a new one
MessageEdit {
body: String,
id: MessageId
},
MessageDelete {
id: MessageId
},
// State Actions
StateCreate {
path: StatePath,
ty: StateType,
permissions: Option<Vec<StatePermission>>
},
StateWrite {
path: StatePath,
content: StateValue
},
StateDelete {
path: StatePath,
},
StateAppend {
path: StatePath,
content: StateValue
},
StateMove {
path: StatePath,
target: StatePath,
},
StateRead {
path: StatePath
},
PermissionAdd {
permission: StatePermission
},
PermissionDelete {
permission: StatePermissionKey
},
// Groups really should have a way to add permissions by user
// specifically for who can join or invite others
//
// Maybe make a group -> role -> member hierarchy?
//
//
// Could always do this through a bot that owns a group??
GroupCreate {
group: Group,
users: Vec<User>
},
// Only the creator of a group or a server admin can delete groups
GroupDelete {
group: Group
},
// Only the creator of a group or a server admin can delete groups
// same with adding, though there should be a way to add group officers
// at some point
GroupUserAdd {
group: Group,
users: Vec<User>
},
GroupUserRemove {
group: Group,
users: Vec<User>
},
GroupRoleCreate {
group: Group,
role: Role
},
GroupRoleDelete {
group: Group,
role: Role
},
GroupRoleUserAdd {
group: Group,
role: Role,
users: Vec<User>
},
GroupRoleUserRemove {
group: Group,
role: Role,
users: Vec<User>
},
// Should work like discord roles
// Can control who can invite to the group
// Can be used with permissions to make rooms that are private for individual roles
GroupRolePowerAdd {
group: Group,
role: Role,
power: GroupPower
},
GroupRolePowerRemove {
group: Group,
role: Role,
power: GroupPower
},
// Returns an ID to use for message sending
// The server can potentially use the current username to associate media uploads
// with users
MediaUpload {
#[serde(with = "serde_bytes")]
bytes: Vec<u8>
},
// Join and subscribe
Join {
room_id: RoomId,
},
SubscribeMessages {
room_id: RoomId,
},
SubscribeState {
room_id: RoomId,
state: StatePath
},
FetchMessages {
count: u64,
end: MessageId,
}
}
#[derive(Serialize,Deserialize)]
enum ServerError {
InvalidPermission,
// Server can specify the required challenge
ChallengeInvitecode,
}
#[derive(Serialize,Deserialize)]
enum ServerMessage {
// Returned on fetch or naturally from subscribe
Messages(Vec<Message>),
MediaUploaded(Uuid),
Error(ServerError),
// Returned both on read and from subscribe
State(StateValue),
Ok,
}