Make UUri specification more formal #121

sophokles73 · 2024-04-22T07:15:54Z

This addresses #115 and other issues.

The UUri specification has been lacking many details that are relevant
for correctly implementing the data model in client libraries.

A lot of the specification's textual content has been transformed into
formal requirements based on invariants and predicates expressed using
the Object Constraint Language.

Last but not least, the 'id' and 'ip' properties have been removed from
UAuthority's data model because they did not really serve a specific
pupose beyond the semantics of the 'name' property.

sophokles73 · 2024-04-22T07:21:15Z

Here's my first shot at a UUri spec formalization.

One thing that still bothers me:
The 8-bit length field of the Micro Format allows for the authority to use up to 255 bytes. The name property, on the other hand, contains (unicode) characters which may be encoded into up to three bytes (using UTF8) per character.

This shouldn't necessarily be an issue because most characters used for the logical name will consist of ASCII characters only and those are encoded into a single byte (using UTF8).

However, IMHO we should properly handle cases in which the authority would be encoded into more than 255 bytes. Given that the Long and Short Format do not put any constraints on the authority length, I wonder if we really need to constrain it in the Micro Format.

If we need/want to set a limit, then IMHO we should define this constraint on the Object Model itself. We should then probably only allow ASCII characters in the authority name so that we know upfront, how many bytes it would be encoded into ...

sophokles73 · 2024-04-22T07:23:44Z

@stevenhartley @PLeVasseur @tamarafischer @AnotherDaniel @evshary

any feedback would be welcome

stevenhartley · 2024-04-22T12:55:18Z

Here's my first shot at a UUri spec formalization.

One thing that still bothers me: The 8-bit length field of the Micro Format allows for the authority to use up to 255 bytes. The name property, on the other hand, contains (unicode) characters which may be encoded into up to three bytes (using UTF8) per character.

This shouldn't necessarily be an issue because most characters used for the logical name will consist of ASCII characters only and those are encoded into a single byte (using UTF8).

However, IMHO we should properly handle cases in which the authority would be encoded into more than 255 bytes. Given that the Long and Short Format do not put any constraints on the authority length, I wonder if we really need to constrain it in the Micro Format.

If we need/want to set a limit, then IMHO we should define this constraint on the Object Model itself. We should then probably only allow ASCII characters in the authority name so that we know upfront, how many bytes it would be encoded into ...

@sophokles73 we need to follow RFC3968 which means it cannot be any form of UTF-8 character only those characters listed in Appendix A, a collection of ABNF for URI.

sophokles73 · 2024-04-22T15:39:29Z

we need to follow RFC3968 which means it cannot be any form of UTF-8 character only those characters listed in Appendix A, a collection of ABNF for URI.

Well, for the long and short form URIs that is done by means of percent encoding any illegal characters. However, that also increases the number of ASCII characters in the URI.

For the micro form serialization I do not see why we would be bound by RFC3986. We are not producing a (textual) URI but a custom binary representation and as long as we can recreate the original UUri from it, we should be safe, shouldn't we?

Another approach, of course, would be to restrict UAuthortity.name to only contain ASCII characters in the first place, if that is what you mean.

stevenhartley · 2024-04-22T19:29:12Z

we need to follow RFC3968 which means it cannot be any form of UTF-8 character only those characters listed in Appendix A, a collection of ABNF for URI.

Well, for the long and short form URIs that is done by means of percent encoding any illegal characters. However, that also increases the number of ASCII characters in the URI.

For the micro form serialization I do not see why we would be bound by RFC3986. We are not producing a (textual) URI but a custom binary representation and as long as we can recreate the original UUri from it, we should be safe, shouldn't we?

Another approach, of course, would be to restrict UAuthortity.name to only contain ASCII characters in the first place, if that is what you mean.

Yes, lets restrict to ASCII characters

stevenhartley

Please see comments. Much better than before for sure!

basics/uri.adoc

stevenhartley · 2024-04-22T20:45:46Z

basics/uri.adoc


-[source]
+A UUri can be represented as


Suggested change

A UUri can be represented as

A UUri can be represented as:

stevenhartley · 2024-04-22T20:46:07Z

basics/uri.adoc

-[source]
+A UUri can be represented as
+
+* an instantiation of the <<_data_model,UUri Data Model>> in a supported programming language,


Suggested change

* an instantiation of the <<_data_model,UUri Data Model>> in a supported programming language,

* An instantiation of the <<UUri Data Model>> in a supported programming language

I'd like to refer to the section, not the UML class diagram here ...

It should refer to the section with that title unless you named the title and the diagram the same. The reason why I proposed the change is that the link did not work for me when I rendered it in the PR.

basics/uri.adoc

stevenhartley · 2024-04-22T21:22:35Z

basics/uri.adoc

-|`[1, 1, -128, 0, 0, 0, 3, 0, -64, -88, 1, 100]`
+[source,java]
+----
+public class UUri {


UUri is defined in proto and the classes are generated to which we cannot extend. I recommend we do not show coding examples in this spec but state that serializers and deserializers and validators are required.

Well, that might be true for the tooling you use for generating Java code. For Rust, it is very much possible to add such code to the generated types. In general, I wonder if this specification should be based on the features/shortcomings of proto3 and the language specific tooling, or if we want/need to define a model that serves the purpose of uProtocol best. In that context, I have to admit that I am very unhappy with the fact that the Object Model uses UInt32 types when the domain actually requires UInt16 for identifiers and UInt8 for version_{major,minor}.
FMPOV we should define in the spec what we need and consider right and then point out, that the proto3 definition's sole purpose is to supports serialization and deserialization of a (valid) instance of the object model, but nothing more.

basics/uri.adoc

sophokles73 · 2024-04-23T12:28:06Z

@stevenhartley I have updated according to your feedback but also have added some questions to the comments ...

stevenhartley · 2024-04-23T12:32:02Z

@stevenhartley I have updated according to your feedback but also have added some questions to the comments ...

I answered your questions this morning.

sophokles73 · 2024-04-23T13:18:20Z

@stevenhartley I have updated according to your feedback but also have added some questions to the comments ...

I answered your questions this morning.

@stevenhartley It looks like some of them slipped through ... maybe you haven't seen them because they have been collapsed by GitHub?

sophokles73 · 2024-04-23T15:12:24Z

@stevenhartley I just had a little chat with @AnotherDaniel about his problems using UUris from within his uSubscription implementation which are mainly related to the duality of identifiers (name vs. id) :-)
We ended up thinking out loud about trying to get rid of the numerical id properties in the same way as we did in UAuthority, i.e. leave the resolving of logical names to identifiers to the UTransport that actually requires it. Currently, this would only affect the SOME/IP client if I am not mistaken and we could imagine it maintaining a mapping of names <-> (SOME/IP) ids in very much the same way as we let it do the mapping of names <-> IP addresses.

Would it make sense to think a little more into that direction or is it totally out of the question from your point of view?

stevenhartley · 2024-04-23T19:56:31Z

@stevenhartley I just had a little chat with @AnotherDaniel about his problems using UUris from within his uSubscription implementation which are mainly related to the duality of identifiers (name vs. id) :-) We ended up thinking out loud about trying to get rid of the numerical id properties in the same way as we did in UAuthority, i.e. leave the resolving of logical names to identifiers to the UTransport that actually requires it. Currently, this would only affect the SOME/IP client if I am not mistaken and we could imagine it maintaining a mapping of names <-> (SOME/IP) ids in very much the same way as we let it do the mapping of names <-> IP addresses.

Would it make sense to think a little more into that direction or is it totally out of the question from your point of view?

No we cannot do this (leave it up to the transport layer). The source of truth for service ids is the proto and is known to the application layer code or uDiscovery (not the transport layer). UAuthority to ip address can be done using linux resolver or static IP address table.

AnotherDaniel · 2024-04-23T20:54:07Z

Hm, I hear what you're saying. So pushing ahead with uDiscovery, and making that the source of truth for this kind of lookup - based in the proto definitions - would that be an option?

I really don't like this information-duality between names and ids in the UURi, also the fact that we are redefining/extending what an uri is... feels off. Would much rather have uris just be uris, and have a well defined, separate way to translate to id representation and back (like url - DNS - ip)

stevenhartley · 2024-04-23T23:54:05Z

I'm open to other suggestions and agree when we only had long form URI it was much simpler. I haven't been able to think of a different solution.

AnotherDaniel · 2024-04-24T11:11:57Z

I'm open to other suggestions and agree when we only had long form URI it was much simpler. I haven't been able to think of a different solution.

This might become too big a discussion for this PR - take this out into a dedicated issue maybe?

I'm asking this from my usual clueless point of view - but my thinking would be: shouldn't the up-client/boundary-ustreamers adapters be able to perform name-to-id-to-name translation for the messages that flow by, with the relevant information retrieved from uDiscovery (DNS-style) services?

These uDiscovery entities, within a certain scope (i.e. vehicle), might then address the question of how to efficiently manage their translation tables as some form of distributed configuration, that can be managed as a separate problem to solve (so these tables might be just built from proto definitions, as default/semi-static config, but obviously some form of updatability might be desirable in the future)...

The following works to address #121 by making the contract explicit and to differentiate the old LongForm URI and short form URI.

evshary · 2024-04-25T13:46:00Z

Another approach, of course, would be to restrict UAuthortity.name to only contain ASCII characters in the first place, if that is what you mean.

Yes, lets restrict to ASCII characters

Sorry for disrupting the discussion. I also like the restriction of UAuthority.name, but I'm not sure what the range of ASCII characters here is. Does it only limit to use alphabet and number, or it can also use something like !, +, @, etc?
Also, is the UAuthority.name still case-insensitive?
These are related to whether the character are valid when transforming into protocol topic / key.

sophokles73 · 2024-04-25T14:53:42Z

Sorry for disrupting the discussion. I also like the restriction of UAuthority.name, but I'm not sure what the range of ASCII characters here is. Does it only limit to use alphabet and number, or it can also use something like !, +, @, etc?

In the PR I am currently restricting the authority to be a host following the corresponding production in https://datatracker.ietf.org/doc/html/rfc3986#appendix-A

In particular, this also includes characters from the sub-delim production which also includes !, & etc

Also, is the UAuthority.name still case-insensitive?

Yes, FMPOV that is the plan.

evshary · 2024-04-26T02:46:04Z

In the PR I am currently restricting the authority to be a host following the corresponding production in https://datatracker.ietf.org/doc/html/rfc3986#appendix-A

In particular, this also includes characters from the sub-delim production which also includes !, & etc

OK, then I still need to do some transformation while generating Zenoh key. At least, $ and * are forbidden in Zenoh key.

Yes, FMPOV that is the plan.

Then, no matter MQTT topic or Zenoh key should transform the authority to either lowercase or uppercase, since they are case-sensitive.

Is there any reason why we stick to RFC3986 standard here? If not, how about defining our own UAuthority for our own purpose?

sophokles73 · 2024-04-26T05:56:46Z

Is there any reason why we stick to RFC3986 standard here? If not, how about defining our own UAuthority for our own purpose?

IMHO the biggest advantage is to be able to use tooling that is available for RFC3986 URIs, e.g. for parsing, comparing etc. Most programming languages have support for URIs in some way.

That said, as long as we make sure that a UUri is-a RFC3986 URI, we should be on the safe side. This should indeed allow us to e.g. restrict the supported characters in the host production if we feel that this would be beneficial. Do you have a concrete proposal for that?

evshary · 2024-04-26T06:18:54Z

IMHO the biggest advantage is to be able to use tooling that is available for RFC3986 URIs, e.g. for parsing, comparing etc. Most programming languages have support for URIs in some way.

Totally agree with you.

Do you have a concrete proposal for that?

No, but I'm thinking perhaps using unserved here in UAuthority is enough.

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

Also, limiting the using lowercase (or uppercase) alphabets here might be simpler.
But it's still ok to transform UAuthority into lowercase (or uppercase) in the transport layer (MQTT, Zenoh...).

The following adds to #121 to simplify the datamodel for UUri object.

stevenhartley · 2024-04-30T21:00:41Z

@sophokles73 (et. al.),

I want to summarize conversations over email so we can conclude on this topic. I really don't think we will get a single UUri definition that will map perfectly to all transports so need to to compromise, taking into consideration the ease of use, $ for transmission, and other factors.
Given that we will have to statically map service/topic information for mechatronics anyways (for SOME/IP), I think the "good enough" solution shall be:

Go back to a single definition of a UUri that takes the best of long & short while removing micro all together
Make UAuthority mandatory: Removes ambiguity if present or not and allows for simplifies normalization of UUris
Constrain UAuthority::name and UEntity::name to "unreserved" defined above (and possibly limit size)
Represent UResource as an ID in lieu of name+instance+Message strings: This reduces the size of the UUri while still providing uniqueness for the UResource and flexibility for UEntity naming to number mapping. We keep the definition of id ranges to what we've already defined (i.e. 0 is repsonse, 0-0x7FFFF is request, 0x8000- is publish/notification)

If we settle on above, there is no more need for isResolved(), isLong(0, isShort(), isMicro() and all the other validator logic that is overly complicated. Serializers are simplified back to a single toString() and fromString() and the string format is now:

up://[UAUTHORITY_NAME]/[UENTITY_NAME]/[UENTITY_VERSION_MAJOR][.UENTITY_VERSION_MINOR]/[URESOURCE_ID]

I've captured these changes in #126 . The reason for keeping UAuthority, UEntity, and UResource is to minimize the amount of changes in all the existing code and not to re-invent UUri completely.

sophokles73 · 2024-05-02T07:34:28Z

... and the string format is now:

up://[UAUTHORITY_NAME]/[UENTITY_NAME]/[UENTITY_VERSION_MAJOR][.UENTITY_VERSION_MINOR]/[URESOURCE_ID]

So far, the minor version had not been part of any of UUri's serializations. Just want to make sure that we really need it in there. And if we do, I guess the inclusion of minor version should be dependent on the presence of major version

up://[UAUTHORITY_NAME]/[UENTITY_NAME]/[UENTITY_VERSION_MAJOR[.UENTITY_VERSION_MINOR]]/[URESOURCE_ID]

or be put into a separate path segment

up://[UAUTHORITY_NAME]/[UENTITY_NAME]/[UENTITY_VERSION_MAJOR/[UENTITY_VERSION_MINOR]/[URESOURCE_ID]

However, I'd prefer the former, if we really need minor version in it ...

sophokles73 · 2024-05-13T08:34:26Z

@stevenhartley I have adapted the UUri spec according to the discussed simplifications of the UUri data model. Some things I want to bring to your attention:

I propose to use base16 encoding for the identifiers in the URI which makes them easier to read FMPOV and will also save a few bytes compared to decimal encoding
The host production used for the authority name has not been adapted (yet) to use only unreserved characters as proposed by @evshary. We might want to consider this, though.
With the introduction of explicit wildcard values we no longer support URIs having empty path components. FMPOV this is actually good because it makes parsing much easier and should not have any real impact on message exchanges because the wildcards will only be used in the definition of forwarding rules in a streamer.
I have added OpenFastTrace specification item markup where appropriate. We can use these for testing the OpenFastTrace toolchain before rolling out to other spec documents.

stevenhartley · 2024-05-13T13:48:20Z

@stevenhartley I have adapted the UUri spec according to the discussed simplifications of the UUri data model. Some things I want to bring to your attention:

I propose to use base16 encoding for the identifiers in the URI which makes them easier to read FMPOV and will also save a few bytes compared to decimal encoding

The host production used for the authority name has not been adapted (yet) to use only unreserved characters as proposed by @evshary. We might want to consider this, though.

With the introduction of explicit wildcard values we no longer support URIs having empty path components. FMPOV this is actually good because it makes parsing much easier and should not have any real impact on message exchanges because the wildcards will only be used in the definition of forwarding rules in a streamer.

I have added OpenFastTrace specification item markup where appropriate. We can use these for testing the OpenFastTrace toolchain before rolling out to other spec documents.

I'll take a look. I started to code these things on the 1.5.8 branch of up-java and the serializers and deserializers were drastically simplified as well.

stevenhartley

@sophokles73 only minor comments left but looking much better than before!

stevenhartley · 2024-05-13T14:11:16Z

basics/uri.drawio.svg

You removed the white background so it is difficult to see the image, please add it back.

I agree that this makes it harder to see in vscode (with a dark theme/background). However, when viewing on GitHub this is not an issue, right? The rfc3986.png also has a transparent background so I thought we might want to do the same for the URI diagram ...

stevenhartley · 2024-05-13T14:17:01Z

basics/uri.adoc

-| Returns true if the Uri part contains the required ids to serialized to Micro format and the fields of the Uri can fit within the specified number of bits and bytes. Both sets of details can be obtained under <<Micro URIs>>
+[source,ocl]
+----
+inv: authority_name.length() <= 128


Where did this requirement come from?

We had been discussing that we wanted to limit the length of the authority name to some degree. I just picked 128 as a first shot. Do you still think that we should limit the length?

stevenhartley · 2024-05-13T14:19:14Z

basics/uri.adoc

+--
+A UUri's `ue_id` property value determines the type and instance of service being referred to. +
+The value's _most_ significant 16 bits represent the _service instance_. +
+The value's _least_ significant 16 bits represent the _service type_.


identifier and not type

We usually talk about instances of a certain type, don't we? A service identifier to me suggests that we are talking about a particular instance already, instead of its type.

stevenhartley · 2024-05-13T14:20:53Z

basics/uri.adoc

+[.specitem,oft-sid="dsn~entity-id~1"]
+--
+A UUri's `ue_id` property value determines the type and instance of service being referred to. +
+The value's _most_ significant 16 bits represent the _service instance_. +


We should put a note that a service instance of 0 means "don't care".

I have added that to the section on pattern matching ...

stevenhartley · 2024-05-13T14:25:56Z

basics/uri.adoc

-|Format | Value
+[.specitem,oft-sid="dsn~pattern-matching~1",oft-needs="impl,utest"]
+--
+A UUri that is used as a pattern to match other UUris against


This is duplicated from the sentence above

stevenhartley · 2024-05-13T14:26:28Z

basics/uri.adoc

-|Long
-|`//vcu.veh.gm.com/core.usubscription/3/SubscriptionChange#Update`
+* *MAY* have its `authority_name` set to the `*` (`U+002A`, Asterisk) character in order to match _any_ (including _no_) authority,
+* *MAY* have the _service type_ part of its `ue_id` set to `0xFFFF` in order to match _any_ type,


maybe we need to call it service number to differentiate the instance id?

not sure what you mean, replace service type with service number or replace service instance with service number?

Re-reading some/ip spec for a little inspiration, they have service_id and service_instance_id, no where do we refer to service_id as type hence why I wanted to keep the id or number but not type.

then let's stick to service id and service instance id. I'll update accordingly ...

stevenhartley · 2024-05-13T14:27:52Z

basics/uri.adoc

-|`//vcu.veh.gm.com/core.usubscription/3/SubscriptionChange#Update`
+* *MAY* have its `authority_name` set to the `*` (`U+002A`, Asterisk) character in order to match _any_ (including _no_) authority,
+* *MAY* have the _service type_ part of its `ue_id` set to `0xFFFF` in order to match _any_ type,
+* *MAY* have the _service instance_ part of its `ue_id` set to `0x0000` in order to match _any_ instance,


I like this!! better than what I was thinking and coding in Java...

sophokles73 · 2024-05-14T11:26:06Z

@stevenhartley I have pushed changes and amended your comments. Would you mind taking another look?

stevenhartley · 2024-05-14T13:10:31Z

@sophokles73 not sure if my comment got lost but the diagram needs to have a white background (it was removed) otherwise I cannot view it when using dark mode in github.

sophokles73 · 2024-05-14T14:15:10Z

@stevenhartley I have added the white background and updated the terminology used for ue_id

stevenhartley

LGTM, thanks @sophokles73 !

sophokles73 · 2024-05-14T15:21:57Z

@stevenhartley any idea why the verify-pr check is not completing? Or what it actually does/is, for that matter?

stevenhartley · 2024-05-14T21:52:08Z

@stevenhartley any idea why the verify-pr check is not completing? Or what it actually does/is, for that matter?

It builds the proto to make sure there are no issues with syntax.
@sophokles73 I can't seem to retrigger it on my side, if you push something new (single line change) it should retrigger the workflows

sophokles73 · 2024-05-15T07:42:46Z

@stevenhartley this PR seems to be stuck, I have tried to push some changes but that doesn't seem to resolve the situation. I will now close this PR and create a new one instead ...

sophokles73 · 2024-05-15T07:51:15Z

Reopening to test a theory ...

The UUri specification has been lacking many details that are relevant for correctly implementing the data model in client libraries. A lot of the specification's textual content has been transformed into formal requirements based on invariants and predicates expressed using the Object Constraint Language. Last but not least, the content model of UUri has been drastically simplified, thus removing all ambiguity around serialization and validation. This should make implementation of the object model much easier and improve general interoperability.

sophokles73 added documentation Improvements or additions to documentation enhancement New feature or request labels Apr 22, 2024

stevenhartley mentioned this pull request Apr 22, 2024

Removal of UAuthority id & ip #115

Closed

stevenhartley requested changes Apr 22, 2024

View reviewed changes

stevenhartley mentioned this pull request Apr 23, 2024

Conform Zenoh spec to 1.5.8 #103

Merged

sophokles73 mentioned this pull request Apr 23, 2024

Adding short-form UUri eclipse-uprotocol/up-rust#80

Closed

matthewd0123 mentioned this pull request Apr 23, 2024

MQTT5 - authority -> topic when authority is missing and hostname is a URL #116

Closed

stevenhartley closed this Apr 24, 2024

stevenhartley reopened this Apr 24, 2024

stevenhartley added a commit that referenced this pull request Apr 25, 2024

ShortUUri Definition

0b4ab43

The following works to address #121 by making the contract explicit and to differentiate the old LongForm URI and short form URI.

stevenhartley mentioned this pull request Apr 25, 2024

ShortUUri Definition #123

Closed

sophokles73 mentioned this pull request Apr 30, 2024

Support matching on source and sink address eclipse-uprotocol/up-rust#92

Merged

stevenhartley added a commit that referenced this pull request Apr 30, 2024

Simplification of UUri Data model

fe54fe8

The following adds to #121 to simplify the datamodel for UUri object.

stevenhartley mentioned this pull request Apr 30, 2024

Simplification of UUri Data model #126

Merged

sophokles73 force-pushed the make_uuri_spec_more_formal branch 2 times, most recently from ed93082 to a482912 Compare May 13, 2024 08:34

stevenhartley requested changes May 13, 2024

View reviewed changes

stevenhartley approved these changes May 14, 2024

View reviewed changes

stevenhartley added the v1.5.8 label May 14, 2024

sophokles73 force-pushed the make_uuri_spec_more_formal branch from a4d2d55 to cf383b7 Compare May 14, 2024 15:19

sophokles73 added this to the alpha.1 milestone May 14, 2024

stevenhartley approved these changes May 14, 2024

View reviewed changes

sophokles73 force-pushed the make_uuri_spec_more_formal branch from cf383b7 to bddec77 Compare May 15, 2024 07:38

sophokles73 closed this May 15, 2024

sophokles73 mentioned this pull request May 15, 2024

Make UUri specification more formal #142

Closed

sophokles73 reopened this May 15, 2024

sophokles73 force-pushed the make_uuri_spec_more_formal branch from bddec77 to 13989bd Compare May 15, 2024 07:56

sophokles73 merged commit 8191328 into eclipse-uprotocol:main May 15, 2024
2 checks passed

	* an instantiation of the <<_data_model,UUri Data Model>> in a supported programming language,
	* An instantiation of the <<UUri Data Model>> in a supported programming language

Make UUri specification more formal #121

Make UUri specification more formal #121

Conversation

sophokles73 commented Apr 22, 2024

sophokles73 commented Apr 22, 2024 • edited

sophokles73 commented Apr 22, 2024

stevenhartley commented Apr 22, 2024

sophokles73 commented Apr 22, 2024

stevenhartley commented Apr 22, 2024 • edited

stevenhartley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophokles73 Apr 23, 2024 • edited

Choose a reason for hiding this comment

sophokles73 commented Apr 23, 2024

stevenhartley commented Apr 23, 2024

sophokles73 commented Apr 23, 2024 • edited

sophokles73 commented Apr 23, 2024

stevenhartley commented Apr 23, 2024

AnotherDaniel commented Apr 23, 2024

stevenhartley commented Apr 23, 2024

AnotherDaniel commented Apr 24, 2024 • edited

evshary commented Apr 25, 2024 • edited

sophokles73 commented Apr 25, 2024

evshary commented Apr 26, 2024

sophokles73 commented Apr 26, 2024

evshary commented Apr 26, 2024

stevenhartley commented Apr 30, 2024

sophokles73 commented May 2, 2024 • edited

sophokles73 commented May 13, 2024

stevenhartley commented May 13, 2024

stevenhartley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophokles73 May 14, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophokles73 commented May 14, 2024

stevenhartley commented May 14, 2024

sophokles73 commented May 14, 2024

stevenhartley left a comment

Choose a reason for hiding this comment

sophokles73 commented May 14, 2024

stevenhartley commented May 14, 2024 • edited

sophokles73 commented May 15, 2024

sophokles73 commented May 15, 2024

sophokles73 commented Apr 22, 2024 •

edited

stevenhartley commented Apr 22, 2024 •

edited

sophokles73 Apr 23, 2024 •

edited

sophokles73 commented Apr 23, 2024 •

edited

AnotherDaniel commented Apr 24, 2024 •

edited

evshary commented Apr 25, 2024 •

edited

sophokles73 commented May 2, 2024 •

edited

sophokles73 May 14, 2024 •

edited

stevenhartley commented May 14, 2024 •

edited