[AXS-58] Wallet-based Resolver Plugin

[bernardoaraujor]

Consider the following scenario:

Alice (device owner) delegates access to Bob for certain amount of IOTA tokens (rent fee) which are transferred from Bob wallet to the device.

Afterwards, Alice needs a mechanism to collect her rent tokens.That is done via Token Collection Policy, which contains the following information:

Subject Alice_ID
Object Device_ID
Alice_IOTA_Address
constrains: Time, location...

In order to fulfill Token Collection Policy, there must be an implementation of a Wallet-based Resolver Plugin.

Wallet funcionality is already available. Any questions should be directed to Sam Chen (@oopsmonk).

In current Wallet implementation, there's wallet_ctx_t, which can be seen as analogous to cli_ctx_t in iota_cmder.

JIRA: AXS-58

[bernardoaraujor]

Useful reference: https://youtu.be/M9dwwgtbbOU

[strahinjagolic]

Do we really need to have wallet-based resolver? Whey I see it, we can establish new action, called e.g. collect_tokens, but mechanism for resolving this action can be defined in the demo resolver (in our case), not in resolver interface (resolver.c/resolver.h ), same way as the other actions. I don't see why this action will be different than any other one. In this case, we can include wallet into demo and use it's API when it is requested by the action. Only thing missing from resolver (and, also PEP module) in this case, will be interface for sending Alice's address to the resolver (and later device's wallet). Only parameters that are describing action and currently are supported, are start/end time, so that needs to be refactored.

@bernardoaraujor @vlad-ns I'm I missing something big here? Did I understood this correctly? I will appreciate any second opinion.

[bernardoaraujor]

@oopsmonk what do you think?

[bernardoaraujor]

IMO, the demo approach is just fine.

I agree that the address is important. You can do the necessary refactoring under this task.

[vlad-ns]

@strahinjagolic We can use demo_resolver to send tokens as this is one of the use-cases that can be supported but not mandatory required for access to work. In this way we would have universal resolver that would be generic implementation and use case specific examples will be implemented in demo_resolver.

[bernardoaraujor]

@strahinjagolic @vlad-ns

wallet_ctx_t struct is initialized in main.c and passed as arg during registration of callback for wallet-based resolver in PEP.

does that make sense?

if so, this issue could be correlated with issue #88

[strahinjagolic]

@bernardoaraujor It is passed as parameter for PEP initialization. It has nothing to do with the resolver. To me it makes sense to create wallet in main thread, but context must be somehow passed to access core. I see this as a simpler way of doing it. Having this in mind, it seems that it is correlated with #88

[strahinjagolic]

@oopsmonk Please check latest commits on wallet_b_resolver branch.

After wallet was included to existing code, multiple build/linker errors occurred, so CMakeLists file had to be modified (e.g. access_wallet wasn't visible, so id had to be switch to PUBLIC, 'm' was added to wallet_libs due to error (../_deps/iota.c-build/libcclient.a(prepare_transfers.c.o): undefined reference to symbol 'trunc@@GLIBC_2.4')). Please check if these changes suits you, or, maybe, you have better solution in mind.

[strahinjagolic]

CMakeLists file had to be modified

I forgot to mention, it is CMakeList for wallet, of course.

[oopsmonk]

CMakeLists file had to be modified

I forgot to mention, it is CMakeList for wallet, of course.

I don't see problems with building wallet lib on wallet_b_resolver branch. what are your steps and errors?

$ cmake .. -DCMAKE_INSTALL_PREFIX=$PWD/ext_install
$ make access_wallet
[100%] Building C object wallet/CMakeFiles/access_wallet.dir/wallet.c.o
[100%] Linking C static library libaccess_wallet.a
[100%] Built target access_wallet

[strahinjagolic]

@oopsmonk Now it's OK, because I've changed CMakeList. Please check if you agree with these changes.

[oopsmonk]

@strahinjagolic it looks good for me.

[strahinjagolic]

Done in f40c3a82353e6555f4d8c43faa906f0f2ecc0a68