Open sanity opened 4 weeks ago
If a user is banned then they will no-longer be able to post and their messages will be removed
Maybe it can be good to have an option on the ban function, to choose if their messages should be deleted or not. Sometimes it can be good to see the past messages so that other users can better understand the reason of the ban.
Could you write the initial json template in your specs please?
We should use bincode for serialization, not JSON - it's more efficient.
If I code a bad one, I will have to redo everything!!!
I'm not sure what you mean, you should be able to use the ChatState
struct with serde derive to serialize it.
I've fleshed out ChatSummary
and ChatDelta
.
If a user is banned then they will no-longer be able to post and their messages will be removed
Maybe it can be good to have an option on the ban function, to choose if their messages should be deleted or not. Sometimes it can be good to see the past messages so that other users can better understand the reason of the ban.
Yes, I think that would be a useful option in the future but I think we should keep the design minimalist for now. The main purpose of banning is to deal with spammers, in which case we'll want to remove their messages.
Would banning be akin to pruning an entire sub-tree (e.g. banning bob
automatically bans charlie
too), or flicking out the bad node and adopting its children (e.g. banning bob
turns charlie
into a direct invitee of alice
)? Or would this be an optional decision at ban time?
Would banning be akin to pruning an entire sub-tree (e.g. banning
bob
automatically banscharlie
too), or flicking out the bad node and adopting its children (e.g. banningbob
turnscharlie
into a direct invitee ofalice
)? Or would this be an optional decision at ban time?
I think it would be an optional decision at ban time, whoever is doing the banning has the option of "adopting" anyone downstream of the ban.
wich library do I use for ECC please? I would like an openssl library if possible ideally.
Goal
A proof-of-concept of a simple decentralized group chat system on Freenet that could potentially replace the Freenet Matrix channel.
Features
Limitations
Absolutely, let's refine it for a more concise and technical approach, akin to an RFC (Request for Comments):
Permissioning Mechanism
To address problems like spam, permissioning governs who can speak through a hierarchical structure known as the invitation tree.
Invitation Tree
Each room is created and owned by a designated user, forming the root of the invitation tree. Users invited to the room branch off from the owner, creating a hierarchical structure.
Permissioning Example
Consider the scenario where "alice" invites "bob", who subsequently invites "charlie". If "alice" decides to ban "charlie" from the room, she can directly enforce this action, exercising authority over users invited by her or those invited further down the chain.
In this example:
Command Line App
Command Usage
Create a New Room
To create a new room, use the
create-room
command. This command requires a room name.Create a New User
To create a new user, use the
create-user
command. This command requires a nickname.Join a Room and Chat
To join an existing room, use the
join-room
command. This command requires the room's public key or name if it has been joined before.Invite a User
To invite a new user, use the
invite-user
command. This command requires the public key of the user to invite and a nickname.Ban a User
To ban a user, use the
ban-user
command. This command requires the public key of the user to ban.Design
Contract Parameters
Contract State
Represents the state of a chat room contract, including its configuration, members, recent messages, recent user bans, and information about a replacement chat room contract if this one is out-of-date.
Contract Summary
Summarizes the state of a chat room contract, must be compact but must contain enough information about the contract to create a delta that contains whatever is in the state that isn't in the summarized state.
Contract Delta
Efficiently represents the difference between two chat room contract states, including configuration, members, recent messages, recent user bans, and a replacement chat room contract. It can be assumed that once replaced, no further changes will be made to a chat room (which means it will be a footgun, so extreme care will be necessary when upgrading a contract).
Local Data Storage
Use a library like confy for storing local configuration in whatever way is standard for the OS. The CLI should store:
Best Practices
--help
or-h
flag for each command to provide users with guidance on usage directly from the CLI.cr
forcreate-room
,cu
forcreate-user
).list-rooms
,remove-room
).