Developer FAQs

Our FAQ is frequently updated to ensure you have access to the latest information and guidance

How much time does it take to integrate?

It will take 1 day of work considering the following things are completed:

• client-key and client-secret from the Komet team

• Functioning app

• Designs and logic for wallet integration

Which chains are supported by the wallet?

The SDK modules support Matic, ETH, and other EVM-compatible chains.

Is the wallet cross-compatible with Komet App and Partners?

Yes, users signed up using partners SDK will have the same login credentials for the Komet app. It is built cross-compatible to allow single identity across partners(including Komet).

Where can I test the wallet experience and features?

All the modules available in SDK can be tested at app.komet.me (login with Komet wallet)

Are the SDK modules customisable?

Yes, based on product requirements - our team delivers modules catering to business needs.

Eg. NFT Minting

Do you have integration support?

Yes, we support 24 *7 integration queries via the Telegram channel. Calendly meetings with our technical experts on short notice are also an available option.

What is required from Komet to make the integration possible?

client-key and client-secret from the Komet team will be provided once this form is filled. Which type of API call, or JWT (JSON web token) is implemented to ensure security, where are they signed by which party?

In Komet, JWT (JSON Web Token) is used to ensure secure transmission of information between parties. The JWT is signed by Komet's server and contains encoded information about the user. When a user logs in, the server generates a JWT, signs it, and sends it to the user. The user then includes this JWT in the header of their requests to authenticate themselves. The server validates the JWT by verifying its signature. This method allows for stateless authentication, as the server does not need to keep a record of individual tokens.

How key management interaction works within API for different platforms (Komet, Bharatbox or other metaverse)?

Komet manages key interaction within APIs for different platforms such as Komet, Bharatbox, or other metaverse using Google Access token and zk. The partner requests a signer with the user's bearer token and the partner's credentials. In response, the Komet server provides an encrypted signer that can only be decrypted using the partner's credentials.

Describe what all different tokens (app, Json web, komet, cookies) what all are used here and their respective utilisation?

We use JSON Web Tokens (JWT) and Google Access Token for authorization and key management. JWT is a compact, URL-safe means of representing claims to be transferred between two parties. It is used to authenticate requests to the server. Google Access Token, on the other hand, is used to authenticate the application, allowing it to interact with Google APIs. This combination provides a robust security framework for managing access to resources and operations.

What level of encryption, traffic handling, security frames, and, backup implemented at Komet?

We utilize Advanced Encryption Standard (AES) and Secure Hash Algorithm (SHA) as encryption algorithms in conjunction with an API gateway to ensure the security of our requests. This approach helps safeguard the integrity and confidentiality of data as it is transmitted between different systems, further enhancing the security of our operations.

What if use lost connection during transactions, how the transaction security at multiple layers work between partners and Komet?

Blockchain transactions work through a process of validation and consensus among network participants. When a transaction is initiated, it is grouped together in a block with other transactions. These blocks are then verified by network participants (called miners in the case of Bitcoin), and once verified, the block is added to the blockchain.

If a user loses connection during a transaction, the transaction may not go through. However, because blockchain networks are distributed and decentralized, the network itself will continue to operate. Once the user regains connection, they can initiate the transaction again. The security of transactions is maintained through cryptographic algorithms, and a transaction once added to the blockchain cannot be altered or removed, ensuring the integrity and security of the data.

It's important to note that the specific behavior can vary depending on the blockchain protocol and the nature of the transaction. But generally speaking, loss of network connection will not compromise the security of the transaction or the blockchain network. Can you explain the flow architecture and data flow for our API gateway ?

The process flow for requests coming through our API gateway. Here's a step-by-step breakdown:

API Gateway Request Handling:

When a request is made to /api.getitem.io/1/api/, it first passes through the API gateway. The gateway employs a Request ID filter (X-REQUEST-ID) to validate the incoming request ID received from the UI. Request ID Validation:

It checks if the request ID exists in Redis with a TTL (time-to-live) of 30 minutes. If the request ID is found, it implies a repeated request, and a 400 Bad Request error is returned to the user, indicating no data will be sent. Checksum Verification:

If the request ID is not found in Redis (indicating a new request), the flow proceeds to a Checksum Filter where X-REQUEST-Checksum is verified. This filter examines the checksum value against the payload, request ID, and a secret key to ensure the request's integrity and authenticity. Checksum Outcome:

If the checksum is invalid, an Unauthorized 401 error is returned, indicating that the request has been tampered with or is otherwise inauthentic. If the checksum is valid, the flow continues to the next stage. Token Verification Service:

The request is then sent to a Token Verification Service using gRPC (Google Remote Procedure Call). This service checks the Authorization token which should be valid for 7 days, and X-FEA-SESSION for the fingerprint session, which should be valid for 24 hours. The gateway caches the valid session response for 15 minutes to expedite future requests. Downstream Service Calls:

Once verified, the request is forwarded to the appropriate downstream services to process the call and generate the required response. Response Handling:

The downstream services send the response back to the API gateway. A Response Data Filter might be applied at this stage before the final response is sent back to the UI. This flow ensures that the API gateway effectively manages request authentication, validation, and routing, providing a secure and efficient means of handling API calls.