Posts by abe13abe

We are missing the permission kadi.usercommand.setsecret to be able to set the password for the new API/Websockets with the command /user setsecret <password>.

But by stealing the one time password from the WebsocketTest-Link, I was able to get the login, ws-connection and Desktop-requests working. I assume the Transaction-APIs etc are not migrated to the new api (401 with old login method and 404 with x-auth-token)?

Not really an error, but the s200.etm.dev-Frontend uses the hardcoded displayName "Kademlia" from the login-response as the name in the top right and for the first get-request of the desktop image, but that should solve itself when the login-request (or profile-/... in the future) returns the correct username. Subsequent updates from the websocket are working.

Quote from Kademlia

Something like this should now work:

Code

https://s200.etm.dev/transaction/Kademlia/after/0Y1QW1N2

path = "/{username:.+}/after/{transactionId:.+}"

Seems to be working . Is there a limit on the number of transactions returned?

The timestamp attribute of the transaction itself seems to be broken. It returns 0 for all of them (not only for endpoint after, but also for latest and day/month) :

[
    {
        "id": "40VKDGPY",
        ...
        "type": "UBI",
        ...
        "timestamp": 0
    },
    {
        "id": "941977PJ",
        ...
        "type": "KShop",
        ...
        "timestamp": 0
    },
    {
        "id": "251OKZVN",
        ...
        "timestamp": 0
    },
    {
        "id": "69P6ZGPM",
        ...
        "timestamp": 0
    }
]

Yes, overall it wouldn't be that much more complicated.

With Websockets you just have a lot more "management" to do (depending on your library), like handling authentication (browser websockets don't support headers, if I remember correctly. So you would, for example, have to send your credentials as a message and handle the response (success vs failure)), have to tell the server which events you are interested in (and handle the response, if you are not automatically subscribed to all), have to handle disconnections (reestablish connection and after it is established do the "normal" http request to make sure you didn't miss anything).

But I will most likely adapt to the technology you are using

So the code could look similar to this (and now that I have kind of written it anyway, I would be fine with Websockets ). Line 59-70 in a loop would be all you need for long polling as a client.

connect() {
    this.ws = new WebSocket("https://s200.etm.dev/websocket", ["etmProtocol"]);
    this.ws.onmessage = this.handleWsMessage.bind(this);
    this.ws.onopen = event => this.ws.send('{"type": "helloMessage", "data": {"username": "125m125", "token": "<token>");
    this.ws.onclose = this.ws.onerror = evt => {
        if (this.active) {
            // TODO: backoff and so on
            this.connect();
        }
    }
}

handleWsMessage(messageString) {
    const message = JSON.parse(messageString);
    switch(message.subject) {
        case "helloResponse": 
            if (message.data.success) {
                this.ws.send('{"type": "channelsubscription", "data": {"channels": ["chat", "transaction", "..."]}}'} // we could potentially send the channelsubscriptions with the helloMessage
            } else {
                // TODO inform about wrong credentials
                this.active = false;
            }
            break;
        case "channelsubscriptionResponse":
            if (message.data.success) {
                this.catchUpWithMissedEntries()
            } else {
                // TODO unknown channels?
            }
            break;
        case WsSubject.Chat:
        this.chatSubject.next(msg.data);
        break;
      case WsSubject.Transaction:
        this.transactionSubject.next(msg.data);
        break;
      case WsSubject.Mail:
        this.mailSubject.next(msg.data);
        break;
    }
}

catchUpWithMissedEntries() {
    this.channels.forEach(c => {
        switch(c) {
            case 'transaction': 
                this.requestTransactionsAfter(this.transactionSubject.getValue());
                break;
            // ...
        }
    });
}

requestTransactionsAfter(transaction) {
if (!transaction) {
//TODO first request
return;
}
    var myHeaders = new Headers();
myHeaders.append("Auth", "{\"userName\":\"125m125\",\"secret\":\"<secret>\"}");

var requestOptions = {
  method: 'GET',
  headers: myHeaders,
  redirect: 'follow'
};

fetch(`https://s200.etm.dev/transaction/125m125/after/${transaction.id}`, requestOptions)
  .then(response => response.json().forEach(this.transactionSubject.next.bind(transactionSubject)) //TODO: With ws we have to filter for duplicates
  .catch(error => console.log('error', error));
}

Quote from Kademlia

Probably not. If i go to that length it will most likely be websockets. Afaik they win the pros/cons fight over long polling (and i've done that already)

I agree that Websockets are most likely a lot better, especially if you are able to watch multiple "topics" for changes. Just thought I could try my luck, since long polling requests are a lot easier to implement for clients that don't really have to worry about performance/open connections/... .

If you are planning to use the websocket only for sending updates from the server to the client, server sent events could potentially also be interesting, although I have to admit, that I have never used them before.

Hey,

as already talked about on the stream, I would love if you could get all transactions that were executed after another transaction. This would allow clients to get all unknown transcations without having to go through all days/months manually. Also, if I was to check multiple times a day if a new transacation took place, I wouldn't have to request the entire day all the time, but could instead call "after" with the latest known transaction.

When first discussed on the stream, you meant that you would probably do this offstream, since this would require you to restructure the database for you to be able to query this efficiently.

Example:

https://s200.etm.dev/transaction/[UserName]/after/[TransactionId]

called as https://s200.etm.dev/transaction/125m125/after/GVDLYD0P could return

{
  latest: true, // false, if for example more than 100 transactions took place after the requested transactionid and the limit is 100. If false, the client would have to request the next "page" by calling the after-api with the last entry from the array. If there is no limit, only the entries-array could be returned.
  entries: [ // sorted ascending by timestamp, so starts with the one closest to the requested transaction and stops with the closest to the current date
    {
        transactionId: "X1JR928V", // first transaction after GVDLYD0P
        timestamp: 1600682900486
        ...
    },
    {
        transactionId: "Y1QJ49XV",
        timestamp: 1600682991008,
        ...
    },
    ... 
  ]
}

Bonus points, if the API supported long-polling requests, which don't return an empty array but instead block until a new transaction arrives, if the requested one is currently the latest one. This should then probably be configurable with a query parameter, for example https://s200.etm.dev/transaction/125m125/after/GVDLYD0P?longpolling=true