-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: chat scaffold #5244
feat: chat scaffold #5244
Conversation
2ee0044
to
300fa2d
Compare
1c8cd19
to
deffd19
Compare
ee8560f
to
848d3d7
Compare
a8259ea
to
e81351a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, I just have some comments about the cucumber scenarios.
Given I have a seed node SEED_A | ||
When I have a chat client CHAT_A connected to seed node SEED_A | ||
When I have a chat client CHAT_B connected to seed node SEED_A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it still necessary to have the 3rd party base node here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without the seed node the two chat clients don't seem to find each other after being added as contacts. We would probably need to introduce a peer dialing step for new contacts if the client doesn't otherwise have connectivity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can register an issue to monitor if this will be a problem for the mobile wallets, as they will most probably not connect to the same base node at startup.
e246d5a
to
ceb8ec2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good
base_layer/contacts/migrations/2023-03-14-101758_create_messages/up.sql
Outdated
Show resolved
Hide resolved
base_layer/contacts/src/contacts_service/storage/types/contacts.rs
Outdated
Show resolved
Hide resolved
pub address: Vec<u8>, | ||
node_id: Vec<u8>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats the reason we have both here?
address = [node_id][CRC + network]
Asking the node id from address is a simple slice read
pub address: TariAddress, | ||
pub node_id: NodeId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked above, but same here, why store both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, not sure. This code was moved in the refactor, not written new for this PR.
ceb8ec2
to
46f710b
Compare
This refactor reorganizes the contacts crate and builds out the possibility of sending messages to contacts via the already running comms services. Messages will be monitored for and stored locally for the client to retrieve and present in whatever form.
These references are out of date after the refactor and just needed a little guidance.
This provides a barebones chat client used for testing within cucumber. The client is relatively isolated from the test suite itself and could be expanded on in the future.
I was using the default encryption method, which happens to be plaintext. This caused all messages to go out unencrypted and allowed all clients to receive and read all messages. With the appropriate encryption methods client can't read messages not for them, and ignore them, or SAF.
Update the log4s to include the refactoring of contacts and surrounding services.
The ids shouldn't increment per client this would be a useless function. Having a single message between two clients share a common uuid increases ease of integration for future functionality such as validation messages have arrived and read receipts etc.
Instead of changing the default impl of an existing function, move the old function to the unencrypted name, make the new function with an encrypted name, and let any call to the old api fail.
f4edc95
to
ee230a5
Compare
Ack |
## [0.50.0-pre.1](v0.50.0-pre.0...v0.50.0-pre.1) (2023-05-08) ### Features * add miner timeout config option ([5331](#5331)) ([aea14f6](aea14f6)) * chat ffi ([5349](#5349)) ([f7cece2](f7cece2)) * chat scaffold ([5244](#5244)) ([5b09f8e](5b09f8e)) * improve message encryption ([5288](#5288)) ([7a80716](7a80716)) * **p2p:** allow listener bind to differ from the tor forward address ([5357](#5357)) ([857fb55](857fb55)) ### Bug Fixes * add SECURITY.md Vulnerability Disclosure Policy ([5351](#5351)) ([72daaf5](72daaf5)) * added missing log4rs features ([5356](#5356)) ([b9031bb](b9031bb)) * allow public addresses from command line ([5303](#5303)) ([349ac89](349ac89)) * clippy issues with config ([5334](#5334)) ([026f0d5](026f0d5)) * default network selection ([5333](#5333)) ([cf4b2c8](cf4b2c8)) * make the first output optional in the wallet ([5352](#5352)) ([bf16140](bf16140)) * remove wallet panic ([5338](#5338)) ([536d16d](536d16d)) * wallet .h file for lib wallets ([5330](#5330)) ([22a3a17](22a3a17))
Description
Motivation and Context
We want to expand Tari's communication network to handle p2p chat services. This PR sets us off in the right direction for the core Tari processes to be able to handle message passing and storage. Currently chat clients will be able to send, and receive messages when online or offline. Utilizing store and forward for sending communications offline.
How Has This Been Tested?
Via cucumber only. The chat client within cucumber is currently the only interface for trials.
Caveats and known issues