-
Notifications
You must be signed in to change notification settings - Fork 204
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
Add trustping protocol #17
Changes from 3 commits
2d9f61b
aa24251
f2322bc
8134fa8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
import { Handler } from './Handler'; | ||
import { InboundMessage } from '../types'; | ||
import { TrustPingService } from '../protocols/trustping/TrustPingService'; | ||
import { ConnectionService } from '../protocols/connections/ConnectionService'; | ||
import { MessageType } from '../protocols/trustping/messages'; | ||
|
||
export class TrustPingHandler implements Handler { | ||
trustPingService: TrustPingService; | ||
connectionService: ConnectionService; | ||
|
||
constructor(trustPingService: TrustPingService, connectionService: ConnectionService) { | ||
this.trustPingService = trustPingService; | ||
this.connectionService = connectionService; | ||
} | ||
|
||
async handle(inboundMessage: InboundMessage) { | ||
switch (inboundMessage.message['@type']) { | ||
case MessageType.TrustPingMessage: | ||
const { recipient_verkey } = inboundMessage; | ||
const connection = this.connectionService.findByVerkey(recipient_verkey); | ||
if (!connection) { | ||
throw new Error(`Connection for receipient_verkey ${recipient_verkey} not found`); | ||
} | ||
return this.trustPingService.process_ping(inboundMessage, connection); | ||
case MessageType.TrustPingResponseMessage: | ||
return this.trustPingService.process_ping_response(inboundMessage); | ||
default: | ||
throw new Error('Invalid message type for handler'); | ||
} | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
import { InboundMessage } from '../../types'; | ||
import { createOutboundMessage } from '../helpers'; | ||
import { createTrustPingResponseMessage, MessageType } from './messages'; | ||
import { Connection } from '../..'; | ||
import { ConnectionState } from '../connections/domain/ConnectionState'; | ||
|
||
export class TrustPingService { | ||
process_ping(inboundMessage: InboundMessage, connection: Connection) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is perhaps no rule about camelCase method/function naming, my fault. Could you please rename it? And if you want, ESLint rules update would be appreciated :) I understand there will be exceptions, mainly in relation to message attributes defined by spec, but I would recommend to keep it camelCase whenever possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aye aye! |
||
if (connection.getState() != ConnectionState.COMPLETE) { | ||
connection.updateState(ConnectionState.COMPLETE); | ||
} | ||
if (inboundMessage.message['response_requested']) { | ||
const reply = createTrustPingResponseMessage(inboundMessage.message['@id']); | ||
return createOutboundMessage(connection, reply); | ||
} | ||
return null; | ||
} | ||
|
||
process_ping_response(inboundMessage: InboundMessage) { | ||
return null; | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
import uuid from 'uuid/v4'; | ||
|
||
export enum MessageType { | ||
TrustPingMessage = 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/trust_ping/1.0/ping', | ||
TrustPingResponseMessage = 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/trust_ping/1.0/ping_response', | ||
} | ||
|
||
export function createTrustPingMessage(response_requested: boolean = true, comment: string = '') { | ||
return { | ||
'@id': uuid(), | ||
'@type': MessageType.TrustPingMessage, | ||
...(comment && { comment }), | ||
response_requested, | ||
}; | ||
} | ||
|
||
export function createTrustPingResponseMessage(thid: string, comment: string = '') { | ||
return { | ||
'@id': uuid(), | ||
'@type': MessageType.TrustPingResponseMessage, | ||
'~thread': { | ||
thid, | ||
}, | ||
...(comment && { comment }), | ||
}; | ||
} |
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 rather create a handler for each type as it is with other handlers. We can group handlers by a protocol in
handlers
folder. Maybe it's not the best design, but let's keep it consistent for now. Or is there any problem with that I don't see? 🤔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.
uhm no problem as such but I figured it's easy to see all handlers for a particular protocol at one place rather than switching b/w files.
You're right that this breaks consistency with what we have at the moment. I'll split this into two different handlers. Maybe we can have another issue that refactors the handlers and groups them by protocol type? If so, could you create one please?