Feat/164/json output #240

morrieinmaas · 2022-12-14T13:17:52Z

closes #164

Signed-off-by: Moriarty <[email protected]>

TODO: * refactor and rename a a few things Signed-off-by: Moriarty <[email protected]>

Signed-off-by: Moriarty <[email protected]>

NOTE: This is branched off the wallet endpoints already so that needs to be merged first Signed-off-by: Moriarty <[email protected]>

morrieinmaas · 2022-12-14T13:18:11Z

needs #162 to be merged first

Signed-off-by: Moriarty <[email protected]>

berendsliedrecht

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input:
siera --json connection invite
Output:

{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}

berendsliedrecht · 2022-12-14T14:36:09Z

crates/logger/src/lib.rs

+    /// Log level json and nothing else
+    Json,
+


Json should not be a log level. Outputting JSON should not collide with the existing verbosity logs.

berendsliedrecht · 2022-12-14T14:37:03Z

crates/logger/src/macros.rs

+        if ::siera_logger::LogLevel::Json ==
+            ::siera_logger::STATE.read().unwrap().level
+        {
+            println!($($arg)*);


It would be nice here if we format the data, so the user does not have to do this themselves.

ah true. actually better to do this here. what I did now is pass a formatted data blob that is json to this macro by using the pretty_stringify_obj function

morrieinmaas · 2022-12-14T14:47:58Z

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input: siera --json connection invite Output:
{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}

hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

berendsliedrecht · 2022-12-14T15:16:54Z

bit difficult to review, but it does not matter that much.
The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.
Input: siera --json connection invite Output:
{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}
hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

morrieinmaas · 2022-12-14T15:21:09Z

bit difficult to review, but it does not matter that much.
The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.
Input: siera --json connection invite Output:
{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}
hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?
So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else
I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

berendsliedrecht · 2022-12-14T15:38:54Z

bit difficult to review, but it does not matter that much.
The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.
Input: siera --json connection invite Output:
{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}
hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?
So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else
I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.
So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.
Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

morrieinmaas · 2022-12-14T15:46:24Z

bit difficult to review, but it does not matter that much.
The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.
Input: siera --json connection invite Output:
{
  "invitation_url": "https://...=",
  "connection_id": "abcd...xyz"
}
hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?
So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else
I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.
So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.
Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?
No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

Sorry if I'm being daft here. Then we still have the log output in there if doing json? then one would still need to filter somehow the verbosity stuff and separate that from the desired json?! I thought the point was to just get sth that is definitely JSON so it can just be used in unix pipe or some program?

berendsliedrecht · 2022-12-14T16:51:44Z

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input: siera --json connection invite Output:
{

"invitation_url": "https://...=",

"connection_id": "abcd...xyz"

}
hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

Sorry if I'm being daft here. Then we still have the log output in there if doing json? then one would still need to filter somehow the verbosity stuff and separate that from the desired json?! I thought the point was to just get sth that is definitely JSON so it can just be used in unix pipe or some program?

Well just don't have a verbosity flag :). The regular command just displays the "pipable" information. We also have a quiet flag, for stuff like this.

morrieinmaas · 2022-12-14T17:08:02Z

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input: siera --json connection invite Output:

{

"invitation_url": "https://...=",

"connection_id": "abcd...xyz"

}

hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

Sorry if I'm being daft here. Then we still have the log output in there if doing json? then one would still need to filter somehow the verbosity stuff and separate that from the desired json?! I thought the point was to just get sth that is definitely JSON so it can just be used in unix pipe or some program?

Well just don't have a verbosity flag :). The regular command just displays the "pipable" information. We also have a quiet flag, for stuff like this.

Alright I think where this is going. What about the loading spinner then? How do you imagine handling that. As in I'd assume this is a nice feature when not using this to pipe, but when using this for pipe that - if I'm not mistaken - will be part of the output (and undesired) when wanting json.

berendsliedrecht · 2022-12-14T17:12:15Z

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input: siera --json connection invite Output:

{

"invitation_url": "https://...=",

"connection_id": "abcd...xyz"

}

hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

Sorry if I'm being daft here. Then we still have the log output in there if doing json? then one would still need to filter somehow the verbosity stuff and separate that from the desired json?! I thought the point was to just get sth that is definitely JSON so it can just be used in unix pipe or some program?

Well just don't have a verbosity flag :). The regular command just displays the "pipable" information. We also have a quiet flag, for stuff like this.

Alright I think where this is going. What about the loading spinner then? How do you imagine handling that. As in I'd assume this is a nice feature when not using this to pipe, but when using this for pipe that - if I'm not mistaken - will be part of the output (and undesired) when wanting json.

The loader is send to stderr as a convention within unix.

morrieinmaas · 2022-12-14T17:13:39Z

bit difficult to review, but it does not matter that much.

The JSON logger MUST not collide with the verbosity logs and it should just be "log the normal ouput in a json format with a nice key/value, thats it.

Input: siera --json connection invite Output:

{

"invitation_url": "https://...=",

"connection_id": "abcd...xyz"

}

hmmm ok. Wouldn't it make sense to only log the json if json is passed? Was thinking that if only a json value is printed one can easily use siera in a context where you get sth that is json. So if you pipe the output somewhere or use its output to be read by some other program it can load that into whatever datastructure represents json in that lang without having to do any sort of cleaning. Or what is your opinion on this?

So what's happening now is that --json | -j are mutually exclusive with other logging flags plus when using -j it only prints json and nothing else

I understand the point of only showing JSON, and it should not give the default log output, but it should not remove the verbosity logs if specified.

So basically the normal logger should check the state and if it is json we can prettify it (also give it custom keys) and log it like JSOn instead of normal.

Ok I understand what you mean (I think). so then you'd get the normal logs according to verbosity wrapped in JSON and the result is under a key in there like 'result' or sth like that?

No, just the normal logs like the invitation url is in json, the verbosity logs will always stay the same.

Just the output that we always log (with log!()) will be json.

Sorry if I'm being daft here. Then we still have the log output in there if doing json? then one would still need to filter somehow the verbosity stuff and separate that from the desired json?! I thought the point was to just get sth that is definitely JSON so it can just be used in unix pipe or some program?

Well just don't have a verbosity flag :). The regular command just displays the "pipable" information. We also have a quiet flag, for stuff like this.

Alright I think where this is going. What about the loading spinner then? How do you imagine handling that. As in I'd assume this is a nice feature when not using this to pipe, but when using this for pipe that - if I'm not mistaken - will be part of the output (and undesired) when wanting json.

The loader is send to stderr as a convention within unix.

ahhh okayyyyy - thanks for clarifying.

Signed-off-by: Moriarty <[email protected]>

morrieinmaas · 2022-12-14T20:06:35Z

Alright, so changed to your suggestions ( if I got them coeectly). no printing JSON for by default for applicable. Quiet frankly, preferred the previous way (or a version of it) with the flag.

Signed-off-by: Moriarty <[email protected]>

berendsliedrecht

I don't think you understood my point.

Normally we do not want JSON output and we just want it seperated by a new line, like with the connections(uuid \n invitationURL).

When we pass the --json flag, we want the following:

{
  "connection_id": "foo-bar",
  "invitation_url": "https://..."
}

the default behaviour will not change, but it is just swapped with the JSOn logger.

crates/cli/src/modules/credential.rs

crates/automations/src/automations/create_credential_definition.rs

Signed-off-by: Moriarty <[email protected]>

berendsliedrecht · 2022-12-19T17:11:35Z

Is this ready for review?

berendsliedrecht

Quite interested if the macro works. Did you test it? Do you have some output I can see?

crates/cli/src/cli.rs

crates/cli/src/modules/credential.rs

crates/cli/src/modules/wallet.rs

crates/cloudagent-python/src/cloudagent/json_ld.rs

crates/logger/src/lib.rs

crates/logger/src/macros.rs

morrieinmaas · 2022-12-19T17:19:34Z

cheers. Thanks for all the feedback. Will address asap

morrieinmaas · 2022-12-19T17:27:02Z

@blu3beri addressed

Signed-off-by: Moriarty <[email protected]>

berendsliedrecht · 2022-12-19T18:36:48Z

crates/cli/src/modules/wallet.rs

@@ -141,7 +141,7 @@ pub async fn parse_wallet_args(
            };
            agent.create_local_did(options).await.map(|response| {
                loader.stop();
-                log_info!("Successfully created local DID: ",);
+                log_info!("Successfully created local DID: {:?}", response.did);


I don't think we need debug printing for the did (I assume it is a string). If it is not a string we need to convert it.

berendsliedrecht

One more comment.

TimoGlastra · 2022-12-20T07:11:40Z

I'm with @morrieinmaas here. I think it's quite normal for CLIs / tools that when you enable json mode, ALL messages will be printed in json. This way you can parse the logs and make sense of it (structured logging). If you enable verbosity logs, these should also be logged as json imho.

Some examples:

for example tsed has the following structure:

{"startTime":"2017-06-05T22:23:08.479Z","categoryName":"json-test","data":["this is just a test"],"level":"INFO","context":{}},
{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["of a custom appender"],"level":"ERROR","context":{}},
{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["that outputs json"],"level""WARN","context":{}},

Also leaving this: https://stackify.com/what-is-structured-logging-and-why-developers-need-it/

berendsliedrecht · 2022-12-20T08:06:23Z

I'm with @morrieinmaas here. I think it's quite normal for CLIs / tools that when you enable json mode, ALL messages will be printed in json. This way you can parse the logs and make sense of it (structured logging). If you enable verbosity logs, these should also be logged as json imho.

Some examples:

https://logger.tsed.io/layouts/json.html#example

https://tslog.js.org/#/?id=type-pretty-json-hidden

for example tsed has the following structure:
{"startTime":"2017-06-05T22:23:08.479Z","categoryName":"json-test","data":["this is just a test"],"level":"INFO","context":{}},

{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["of a custom appender"],"level":"ERROR","context":{}},

{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["that outputs json"],"level""WARN","context":{}},
Also leaving this: https://stackify.com/what-is-structured-logging-and-why-developers-need-it/

Yes, makes sense. I am not opposed to json verbosity logging, but my point was mainly that logging JSON must not mute the verbosity logs. I think we can address this in a separate PR as it would require reworking the whole logger. We would probably need to always pass a json / struct and create a normal message from that or log it as JSON.

morrieinmaas · 2022-12-20T09:46:26Z

I'm with @morrieinmaas here. I think it's quite normal for CLIs / tools that when you enable json mode, ALL messages will be printed in json. This way you can parse the logs and make sense of it (structured logging). If you enable verbosity logs, these should also be logged as json imho.
Some examples:

https://logger.tsed.io/layouts/json.html#example

https://tslog.js.org/#/?id=type-pretty-json-hidden

for example tsed has the following structure:
{"startTime":"2017-06-05T22:23:08.479Z","categoryName":"json-test","data":["this is just a test"],"level":"INFO","context":{}},

{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["of a custom appender"],"level":"ERROR","context":{}},

{"startTime":"2017-06-05T22:23:08.483Z","categoryName":"json-test","data":["that outputs json"],"level""WARN","context":{}},
Also leaving this: https://stackify.com/what-is-structured-logging-and-why-developers-need-it/
Yes, makes sense. I am not opposed to json verbosity logging, but my point was mainly that logging JSON must not mute the verbosity logs. I think we can address this in a separate PR as it would require reworking the whole logger. We would probably need to always pass a json / struct and create a normal message from that or log it as JSON.

Or not pass json/struct and create json/struct on the fly with eg a timestamp if the/a key is missing but value is present.

I'll have a look into how this can be 'formally' handled as in sticking to some convention

berendsliedrecht · 2023-03-10T08:06:53Z

@morrieinmaas what is the status of this PR?

Moriarty added 5 commits December 13, 2022 15:21

feat: add wallet endpoints

bb3d00f

Signed-off-by: Moriarty <[email protected]>

chore: refactor a little

2583dfa

TODO: * refactor and rename a a few things Signed-off-by: Moriarty <[email protected]>

chore: refactor

d8ef64d

Signed-off-by: Moriarty <[email protected]>

fix: make list args optional

9bde291

Signed-off-by: Moriarty <[email protected]>

feat: json logging

2e81349

NOTE: This is branched off the wallet endpoints already so that needs to be merged first Signed-off-by: Moriarty <[email protected]>

chore: refactor

05ae05f

Signed-off-by: Moriarty <[email protected]>

morrieinmaas marked this pull request as ready for review December 14, 2022 13:40

berendsliedrecht requested changes Dec 14, 2022

View reviewed changes

chore: code review feedback

132160d

Signed-off-by: Moriarty <[email protected]>

chore: remove flag from cli

e058dd2

Signed-off-by: Moriarty <[email protected]>

morrieinmaas force-pushed the feat/164/json-output branch from 7d4956d to e058dd2 Compare December 15, 2022 10:23

berendsliedrecht requested changes Dec 15, 2022

View reviewed changes

crates/cli/src/modules/credential.rs Outdated Show resolved Hide resolved

crates/automations/src/automations/create_credential_definition.rs Outdated Show resolved Hide resolved

Moriarty added 2 commits December 15, 2022 11:44

chore: remove redundant typing

1f2e1ba

Signed-off-by: Moriarty <[email protected]>

chore: refactor and code review feedback

236c40c

Signed-off-by: Moriarty <[email protected]>

morrieinmaas force-pushed the feat/164/json-output branch from 2e48934 to 236c40c Compare December 16, 2022 15:12

chore: merge branch 'main' into feat/164/json-output

77cd5b4

Signed-off-by: Moriarty <[email protected]>

berendsliedrecht requested changes Dec 19, 2022

View reviewed changes

chore: code review feedabck

7b855f5

Signed-off-by: Moriarty <[email protected]>

morrieinmaas force-pushed the feat/164/json-output branch from bf58c6c to 7b855f5 Compare December 19, 2022 17:28

berendsliedrecht reviewed Dec 19, 2022

View reviewed changes

morrieinmaas mentioned this pull request Dec 20, 2022

Unify json and normal logger #242

Closed

berendsliedrecht closed this Mar 12, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/164/json output #240

Feat/164/json output #240

morrieinmaas commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht left a comment

berendsliedrecht Dec 14, 2022

berendsliedrecht Dec 14, 2022

morrieinmaas Dec 14, 2022

morrieinmaas commented Dec 14, 2022 •

edited

Loading

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht left a comment

berendsliedrecht commented Dec 19, 2022

berendsliedrecht left a comment

morrieinmaas commented Dec 19, 2022

morrieinmaas commented Dec 19, 2022

berendsliedrecht Dec 19, 2022

berendsliedrecht left a comment

TimoGlastra commented Dec 20, 2022

berendsliedrecht commented Dec 20, 2022 •

edited

Loading

morrieinmaas commented Dec 20, 2022

berendsliedrecht commented Mar 10, 2023

Feat/164/json output #240

Feat/164/json output #240

Conversation

morrieinmaas commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht left a comment

Choose a reason for hiding this comment

berendsliedrecht Dec 14, 2022

Choose a reason for hiding this comment

berendsliedrecht Dec 14, 2022

Choose a reason for hiding this comment

morrieinmaas Dec 14, 2022

Choose a reason for hiding this comment

morrieinmaas commented Dec 14, 2022 • edited Loading

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

morrieinmaas commented Dec 14, 2022

berendsliedrecht left a comment

Choose a reason for hiding this comment

berendsliedrecht commented Dec 19, 2022

berendsliedrecht left a comment

Choose a reason for hiding this comment

morrieinmaas commented Dec 19, 2022

morrieinmaas commented Dec 19, 2022

berendsliedrecht Dec 19, 2022

Choose a reason for hiding this comment

berendsliedrecht left a comment

Choose a reason for hiding this comment

TimoGlastra commented Dec 20, 2022

berendsliedrecht commented Dec 20, 2022 • edited Loading

morrieinmaas commented Dec 20, 2022

berendsliedrecht commented Mar 10, 2023

morrieinmaas commented Dec 14, 2022 •

edited

Loading

berendsliedrecht commented Dec 20, 2022 •

edited

Loading