Skip to content
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

Deliver an invite #254

Merged
merged 12 commits into from
Jun 3, 2022
Merged

Deliver an invite #254

merged 12 commits into from
Jun 3, 2022

Conversation

llbartekll
Copy link
Contributor

@llbartekll llbartekll commented May 31, 2022

close #255

  • allows A to register at local registry
  • B resolves A by it's address
  • B sents an invite to A

@llbartekll llbartekll self-assigned this May 31, 2022
@llbartekll llbartekll changed the title Chat Deliver an invite May 31, 2022
Copy link

@sekimondre sekimondre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any problems in merging if this is a proof-of-concept. It's good to keep all types internal until we need any of them to be public.

import Foundation
import WalletConnectUtils

struct ChatRequest: Codable {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are too many RPC request duplicates already. I'll prioritize unifying the JSON-RPC types.

logger: logger,
topicToInvitationPubKeyStore: topicToInvitationPubKeyStore,
inviteStore: inviteStore)
relayClient.socketConnectionStatusPublisher.sink { [unowned self] status in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we move subscriptions from init()? For example in subscriptions() method

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

of course

let engine: Engine
let kms: KeyManagementService
var onInvite: ((Invite)->())?
var onNewThread: ((Thread)->())?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why you decide you use this style of callbacks? ("onInvite: ((Invite)->())?, onNewThread: ((Thread)->())?, onConnected: (()->())?")

As I know we take direction to async and publishers.
For example it could be subject whit returns:

enum Response {
case invite(Invite)
case newThread(Thread)
}

or different publishers like we do in Sign

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think one publisher which returns Enum is more convenient and easy to read

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it will be good to have a singleton wrapper around this class so we can do client<->client tests
and that singleton will expose Combine publishers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added many publisher to be consistent with Sign

but I am not sure if one publisher is better solution 🤔

onConnected?()
}
}.store(in: &publishers)
engine.onInvite = { [unowned self] invite in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to use single style of callbacks I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for public interface definitely

I think that for 1to1 relations old school callbacks are good enough and for 1to_many relations it is best to use Combine as we do

so far engine's callbacks have always 1to1 relation with a client

self.registry = registry

self.kms = kms
let serialiser = Serializer(kms: kms)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long inits. How about factories? And our init() will be like this:

init(registry: Registry, engine: Engine, kms: KeyManagementService) {
        self.registry = registry
        self.engine = engine
        self.kms = kms
    }

let registry: Registry
let logger: ConsoleLogging
let kms: KeyManagementService
let threadsStore = KeyValueStore<Thread>(defaults: RuntimeKeyValueStorage(), identifier: "threads")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default initializers is hard to test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

self.logger = logger
self.inviteStore = inviteStore
self.topicToInvitationPubKeyStore = topicToInvitationPubKeyStore
networkingInteractor.responsePublisher.sink { [unowned self] response in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to separate initializations and subscriptions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example

init() {
self.foo = foo
self.bar = bar

setupSubscriptions()
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah will do it before merge

func invite(account: Account) {
let peerPubKeyHex = registry.resolve(account: account)!
print("resolved pub key: \(peerPubKeyHex)")
let pubKey = try! kms.createX25519KeyPair()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safe unwraps?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will make invite throwing


func accept(inviteId: String) throws {
guard let hexPubKey = try topicToInvitationPubKeyStore.get(key: "todo-topic") else {
throw ChatError.noPublicKeyForInviteId
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is todo-topic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no storage to persist and derive this topic yet

so it just indicates to replace it

let agreementKeys = try! kms.performKeyAgreement(selfPublicKey: pubKey, peerPublicKey: invite.pubKey)
let topic = agreementKeys.derivedTopic()
networkingInteractor.subscribe(topic: topic)
//TODO
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// TODO what? : ]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to complete complete function implementation as it is not publishing yet

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will open another issue for accept etc.

import WalletConnectRelay
import WalletConnectUtils

class NetworkingInteractor {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to reuse NetworkInteractor from sign?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is very good question.

I am afraid that for now it is more difficult to make it generic. And I already recognises some differences

Sign also depends to Sign WCrequests now - and few more

That is definitely something to consider but I think it can be time consuming and not worth it now

@llbartekll llbartekll requested a review from flypaper0 June 2, 2022 10:50
@llbartekll llbartekll merged commit 49e22f2 into develop Jun 3, 2022
@llbartekll llbartekll deleted the chat branch June 3, 2022 06:52
@flypaper0 flypaper0 mentioned this pull request Jun 9, 2022
flypaper0 added a commit that referenced this pull request Jun 9, 2022
* Cleanup Service + SequenceStore refactor (#241)

* Cleanup service

* Clean sessionToPairingTopic

* SequenceStore refactor

* Rename KeyValueStore -> CodableStore

* Deliver an invite (#254)

* Add Chat target, split packages

* savepoint

* Update networking interactor  to decode unencrypted messages

* pass on invite test

* restructure chat's project folder

* Add engine storages

* extract storage domain identifiers

* update logging

* fix schemas

* Update style

* Add publishers to Chat

* rename kv store to codable strore

* UI tests (#242)

* Pairing testcase

* Ping testcase

* ApproveSessionExistingPairing test case

* Unused extensions deleted

* Renamed to RegressionTests

* UITests step on CI

* CleanLaunch instead of deleting app

* Fix test on Real device

* Launch App fix

* Approve engine refactor (#260)

* Approve method moved ApproveEngine

* Reject and wcSessionSubscriptions for ApproveEngine

* Private methods moved in extension

* ApproveEngine errors handlers

* Try on reject

* ApproveEngine moved to callbacks

* Session Settle moved to approve Engine

* onProposeResponse subscription removed

* Reject by proposalId

* Settle moved to approve

* ApproveEngine moved to Controller folder

* typealias removed

* TODO for SettleEngine

* #256 JSON-RPC Package (& Commons) (#261)

* Add Chat target, split packages

* savepoint

* restructure chat's project folder

* fix schemas

* Add JSONRPC and Commons packages

* Moved AnyCodable to Commons

* Fixed test import

* Reintroduces either type

* Add request and response types

* Add simple response decode tests

* Add response ID parsing tests

* Fixed tests typo

* Improved response round trip coding test

* Error response decoding tests

* Invalid response decode tests

* Enabled code coverage for library

* Response decoding tests for structured result values

* Add flexible initializers with tests

* Add descriptions to errors thrown in response decoding

* Renamed response internalResult to outcome

* Basic RPC request decoding tests

* Tests for request empty cases and corner cases

* Add flexible inits for requests

* Add identifier generation inits

* Joined request notification extensions

* Renamed files

* Implemented default JSONRPC error cases

* Declared RPCRequestConvertible as public

* Remove rebase artifacts

* Added debug description to request param primitives error

Co-authored-by: Bartosz Rozwarski <bartus000@gmail.com>
Co-authored-by: André Vants <MisterVants@users.noreply.github.com>
@flypaper0 flypaper0 mentioned this pull request Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants