-
Notifications
You must be signed in to change notification settings - Fork 81
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
draft: Demo for aries vcx #952
Conversation
f37e957
to
0551ab2
Compare
Codecov Report
@@ Coverage Diff @@
## main #952 +/- ##
==========================================
+ Coverage 0.05% 30.38% +30.32%
==========================================
Files 384 422 +38
Lines 21249 26230 +4981
Branches 3835 5084 +1249
==========================================
+ Hits 12 7970 +7958
+ Misses 21236 16041 -5195
- Partials 1 2219 +2218
Flags with carried forward coverage won't be shown. Click here to find out more.
|
7f6fee1
to
ec8b9f3
Compare
164de4b
to
a2ab312
Compare
@gmulhearn as a creator of original issue, do you agree this being in a single file? I think your vision to have 2 files, 1 for alice, one for faber. |
d101979
to
8568afd
Compare
Will we remove the demo after the work mentioned is completed, i.e. integration tests are in such a condition that they fulfill the current purpose of the demo, i.e. to demonstrate aries-vcx usage, as discussed in speaking? |
I'd be in favor, there surely will be a lot of duplication between this and integration tests after refactoring them |
25f1e1e
to
5355c1e
Compare
5dde0a7
to
afcb250
Compare
5355c1e
to
11cbec1
Compare
f1a5366
to
7933912
Compare
demo/src/demo_agent.rs
Outdated
} | ||
|
||
pub async fn prepare_invitation(&self) -> (Invitation, PairwiseInfo) { | ||
let (faber_pw_did, faber_invite_key) = self.wallet.create_and_store_my_did(None, None).await.unwrap(); |
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.
nit; not sure if you were looking for it , but you could also call PairwiseInfo::create(wallet)
to avoid construction of PairwiseInfo
at the end
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 would like us to actually get rid of the whole PairwiseInfo
thing, which why I am not using it, rather creating it as necessity at the point where it's needed.
The "did" portion of PairwiseInfo
is generally useless
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 really awesome, nice work. preemptive approval from me; just some comments to consider. (assuming others are happy too ocourse)
|
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.
Mostly left remarks.
I think the message sending could be improved, but that would require quite a bit of a refactor. The duplicate methods should be easy to remove though, which is why I'd request some changes.
2d7eb63
to
9d42c55
Compare
98f2b17
to
c217af7
Compare
demo/src/mpsc_registry.rs
Outdated
#[derive(Clone)] | ||
pub struct MpscRegistry<T: Debug> { | ||
sending: Arc<RwLock<HashMap<String, mpsc::Sender<T>>>>, | ||
receiving: Arc<RwLock<HashMap<String, mpsc::Receiver<T>>>>, | ||
} |
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.
Wasn't the previous implementation similar to this in terms of communication? Maybe I'm missing something but I don't get why the shared ownership and interior mutability is needed.
Each agent should be in charge of its own connections (senders to other agents and receivers from other agents) and practically own them exclusively. Or is there some reason why this can't be achieved?
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
ab545cc
to
58f03a7
Compare
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Signed-off-by: Patrik Stas <patrik.stas@absa.africa>
Archiving this. Instead, a new demo will be created soon on top of |
Partially addressing #870
simple_message_relay
to enable its consumption also as library, rather than executable onlysimple_message_relay
with mpsc channels which forward any incoming message to mpsc receiver. This is nice because in the demo, we don't need to poll HTTP API for new messages - but rather instantly get notified in-memory.Having to interact with aries-vcx from scratch from new application, some improvements I've identified:
Note
This can be thought of as temporary solution to demonstrate the APIs and usage. And while far from ideal yet (todos left, issues created), it's a lot easier to understand than pointing someone to integration tests today. Main issue of integration tests is that they are all couploed with vcxagency-node mediator, but also other issues.
After integration tests are in better shape after:
I believe that integration tests could be in condition to demonstrate the usage (and surface outstanding API issues) equally good as this demo.
But for the time being, this demo is a lot simpler than the existing integration tests.
Demo
Running the demo produces following logs
![image](https://private-user-images.githubusercontent.com/2149283/265469451-704b8a48-d6cb-4cd2-8c5b-4b4cd1abaca6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5NjU2MTUsIm5iZiI6MTcyNTk2NTMxNSwicGF0aCI6Ii8yMTQ5MjgzLzI2NTQ2OTQ1MS03MDRiOGE0OC1kNmNiLTRjZDItOGM1Yi00YjRjZDFhYmFjYTYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTBUMTA0ODM1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NjVmNTZlNDU0OWNiNzMzMzk1OGRhZWJkZDUxYTA2ZmUxMzJhYTlmYmJkZTJjNGVjYTk4ZTRmNTRkMjU5N2NjNSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.ctg_Ap7yQ60N2Nvwinrgfy53rUvnrY1cW2Y4rkH1TUM)