-
Notifications
You must be signed in to change notification settings - Fork 180
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
Deliver an invite #254
Conversation
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 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 { |
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.
There are too many RPC request duplicates already. I'll prioritize unifying the JSON-RPC types.
Sources/Chat/Chat.swift
Outdated
logger: logger, | ||
topicToInvitationPubKeyStore: topicToInvitationPubKeyStore, | ||
inviteStore: inviteStore) | ||
relayClient.socketConnectionStatusPublisher.sink { [unowned self] status in |
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.
Could we move subscriptions from init()
? For example in subscriptions()
method
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.
of course
Sources/Chat/Chat.swift
Outdated
let engine: Engine | ||
let kms: KeyManagementService | ||
var onInvite: ((Invite)->())? | ||
var onNewThread: ((Thread)->())? |
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.
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
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.
But I think one publisher which returns Enum is more convenient and easy to read
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 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
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 added many publisher to be consistent with Sign
but I am not sure if one publisher is better solution 🤔
Sources/Chat/Chat.swift
Outdated
onConnected?() | ||
} | ||
}.store(in: &publishers) | ||
engine.onInvite = { [unowned self] invite in |
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.
We need to use single style of callbacks I think
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.
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) |
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.
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
}
Sources/Chat/Engine.swift
Outdated
let registry: Registry | ||
let logger: ConsoleLogging | ||
let kms: KeyManagementService | ||
let threadsStore = KeyValueStore<Thread>(defaults: RuntimeKeyValueStorage(), identifier: "threads") |
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.
default initializers is hard to test
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.
sure
Sources/Chat/Engine.swift
Outdated
self.logger = logger | ||
self.inviteStore = inviteStore | ||
self.topicToInvitationPubKeyStore = topicToInvitationPubKeyStore | ||
networkingInteractor.responsePublisher.sink { [unowned self] response in |
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.
need to separate initializations and subscriptions
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.
For example
init() {
self.foo = foo
self.bar = bar
setupSubscriptions()
}
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.
yeah will do it before merge
Sources/Chat/Engine.swift
Outdated
func invite(account: Account) { | ||
let peerPubKeyHex = registry.resolve(account: account)! | ||
print("resolved pub key: \(peerPubKeyHex)") | ||
let pubKey = try! kms.createX25519KeyPair() |
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.
safe unwraps?
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.
will make invite throwing
|
||
func accept(inviteId: String) throws { | ||
guard let hexPubKey = try topicToInvitationPubKeyStore.get(key: "todo-topic") else { | ||
throw ChatError.noPublicKeyForInviteId |
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.
what is todo-topic
?
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.
there is no storage to persist and derive this topic yet
so it just indicates to replace it
Sources/Chat/Engine.swift
Outdated
let agreementKeys = try! kms.performKeyAgreement(selfPublicKey: pubKey, peerPublicKey: invite.pubKey) | ||
let topic = agreementKeys.derivedTopic() | ||
networkingInteractor.subscribe(topic: topic) | ||
//TODO |
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.
// TODO what? : ]
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.
to complete complete function implementation as it is not publishing yet
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 will open another issue for accept etc.
import WalletConnectRelay | ||
import WalletConnectUtils | ||
|
||
class NetworkingInteractor { |
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 possible to reuse NetworkInteractor
from sign?
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.
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
* 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>
close #255