-
Notifications
You must be signed in to change notification settings - Fork 200
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(core): d_m invitation parameter and invitation image #456
feat(core): d_m invitation parameter and invitation image #456
Conversation
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Signed-off-by: Berend Sliedrecht <berend@animo.id>
Nice to have these invitation improvements, and actually I find very useful to have that I'm asking this because maybe there are other implementations that use other metadata to make invitations 'user-friendlier' and other fields would be needed to use the framework with them. |
Codecov Report
@@ Coverage Diff @@
## main #456 +/- ##
==========================================
+ Coverage 85.67% 85.68% +0.01%
==========================================
Files 253 253
Lines 5451 5457 +6
Branches 839 841 +2
==========================================
+ Hits 4670 4676 +6
Misses 781 781
Continue to review full report at Codecov.
|
I found it from decoding the trinsic invitation, but I can take a look if it is specified in any RFC. I will take a look tomorrow and get back to you! |
@genaris I have checked around in the rfcs, but I could not find any other metadata for the invitation. If you have other data we can always discuss that during a working group call. However, we should really keep the invitation as small as possible. A large invitation means a large QRcode which is always annoying :-) |
This is not native to the Aries RFCs but more an non-standard extension that a lot of wallets use (e.g. Lissi, Connect.Me, Trinsic) |
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.
Nice!
I think we may get away with using a smaller lib instead of the URL polyfill (e.g. query-string
package). But this looks fine to me for now
d_m
invitation parameter in the url