add Type Index Section by ebremer · Pull Request #115 · w3c/lws-protocol

ebremer · 2026-03-30T19:39:36Z

The type index is the simplest, basic "query" mechanism.

It is a registry that advertises which types exist in storage and exactly which containers hold resources of each type. Clients use it to discover types and retrieve matching resource URIs, - all server-enforced for authorization.

Advanced queries are out of scope.

additional reference

Preview | Diff

acoburn · 2026-03-30T21:06:42Z

I have a few high-level questions about how this service is intended to work.

First, the server will need to identify which resources are indexed with which types. Does every resource get indexed? What is used as a type value? A link header (e.g., rel=type) or an RDF property (for RDF documents)? What happens if a client submits a JSON-LD document? MUST the server perform a full parse of that input (this has significant security implications). In the input document, a client decides which resources are indexed, but I do not see a mechanism by which a client can signal that certain resources are indexed and other are not. Here, the question is primarily: do clients populate the type index or do servers?

Second, where does the default field come from? Who sets that and how is it managed or changed? There is no definition/explanation for that property.

Third, the location field is unclear. Does the value of that field indicate where such resource types can be found or stored, or does that field indicate resources with that type? In other words, if I am a client and I want to add an entry to a resource of type "Foo", are the location values containers that I would POST to, or are they resources that I would append to (via PUT or PATCH)?

Fourth, the TypeIndexService points to a serviceEndpoint, and that serviceEndpoint points to a separate searchEndpoint. It seems like those are two separate features that have related, but slightly different APIs. The purpose of each is not clearly articulated.

Finally, should this feature be defined in a separate document, as is the case for the Access Request feature?

gibsonf1 · 2026-03-30T21:21:40Z

The type index is the simplest, basic "query" mechanism.

It is a registry that advertises which types exist in storage and exactly which containers hold resources of each type. Clients use it to discover types and retrieve matching resource URIs, - all server-enforced for authorization.

Advanced queries are out of scope.

additional reference

Preview | Diff

The Solid client Type Index spec was trying to simulate type search in the only way they could as clients using containers. We should have a simple type search that has nothing to do with CRUD - that is covered elsewhere in the spec. How an implementation implements the search should not be specified. The discussion with respect to search at the last FTF meeting was to have type search rather than a more comprehensive search. The Type Index using containers as clients implementation doesn't make much sense when a server is involved.

I think we should rename this Type Search (and not reference the client based Type Index implementation terminology)

elf-pavlik · 2026-03-31T00:59:33Z

+
+  <section>
+    <h4>Security</h4>
+    <p>Servers MUST enforce authorization per access grants. Responses to GET/POST on <code>TypeIndexService</code> or <code>searchEndpoint</code> include only types, defaults, locations, and resource URIs the authenticated client may read (via grants). Unauthorized entries omitted. Grant listing implicitly yields a client-specific type index.</p>


I think there should be some required consistency between Access Grants and type indexes. In SAI access grants also serve as type index which besides type and location also provides information about access modes and in the future can include usage policies. Currently there is no default equivalent but I see a need to incubate this future with focus on UX. As for consistency, Besides public read and indexed resources. For all other protected resources which are not public read and not publicly indexed. Is application expected to check both, access grants where it is the assignee and known type indexes? What if those two diverge? I understand that the intention is to have access grants and type indexes as two independent features but they should still reflect some common source of truth.

It makes no sense to be putting things in containers by type - what if something has more than one type? (Most things do) etc. This is an implementation idea best left to implementations or to clients. To create containers and put things in them, that seems to already be covered by other parts of the spec.. What is not currently possible (solid spec) is search on a storage by type no matter where something is - this is only possible with a server type search. Search is the foundational feature for most apps, so having a simple type search will get a foot in the door to providing what all apps actually need.

@gibsonf1 I'm not sure if your reply is specific to my comment, type index seems to assume some kind of partitioning by type, which is not a new idea https://www.w3.org/TR/void/#class-property-partitions

My point was mostly abuout consistency with AuthZ. It also isn't a new idea to use access control artifacts for the target resource(s) location discovery

@gibsonf1 I'm not sure if your reply is specific to my comment, type index seems to assume some kind of partitioning by type, which is not a new idea https://www.w3.org/TR/void/#class-property-partitions

@elf-pavlik My point here is that the "Type Index" is a specific client side implementation of an attempt to do type search - which makes no sense in the LWS server spec. We should have a Type Search spec here instead which has no specifics on how an implementation might do things, as opposed to the case in the Solid Client Type Index implementation spec.

I think my other comment could be releavant here. Without references to requirements, and through them to use cases, it may not be clear what this proposal intends to satisfy.

I agree with @elf-pavlik. The field of search is extremely broad, and without clear reference to requirements, it will be challenging to define a proposal that satisfies the entire WG.

My understanding is that the specific requirements are based on a need for basic data discovery (distinct from service or capability discovery). In addition, this needs to be implementable by the widest range of servers in an interoperable way. Furthermore the design needs to draw on prior art so that we don't define something that no one will use.

In no way should the type index mechanism interfere with an implementation offering other query endpoints.

I agree with @elf-pavlik. The field of search is extremely broad, and without clear reference to requirements, it will be challenging to define a proposal that satisfies the entire WG.

My understanding is that the specific requirements are based on a need for basic data discovery (distinct from service or capability discovery). In addition, this needs to be implementable by the widest range of servers in an interoperable way. Furthermore the design needs to draw on prior art so that we don't define something that no one will use.

In no way should the type index mechanism interfere with an implementation offering other query endpoints.

The agreed to requirement at the F2F was to limit search to a simple type search. This is far less precarious than trying to spec out a client implementation of a type index to try to simulate type search. And is there any in production server based "type index" anywhere? I think not.

elf-pavlik · 2026-03-31T01:09:57Z

+  "next": "..."
+}
+    </pre>
+    <p><code>searchEndpoint</code> REQUIRED.<br><code>default</code> OPTIONAL.<br><code>location</code> array of container URIs (always an array).</p>


Which use cases and requirements the default property intends to address?
I understand that it intends to indicate a default container for given storage. Are there any restrictions on how many default containers for given type can be indicated in a storage, I would expect just one.
When user has multiple storages, if application has access to discover indexes for given type across some of those storages, there still can be a friction with identifying default of which storage should be used. I think the design of default needs to be evaluated against use cases and requirements it intends to address.

gibsonf1 · 2026-04-01T15:01:18Z

@pchampin I just saw your presentation at Solid World, and the whole issue you are trying to solve with dealing with files to try to get query is solved with server based /search actually https://www.youtube.com/watch?v=0Vrqn1Ie3c0. (On TwinPod, we would just use search to do all you need there) This is specifically why search is a foundational feature for any app that needs it.

remove "default" field add search endpoint to Storage description

instances can be found with [typeSearchService]

ebremer · 2026-04-02T19:05:03Z

The "default" and "location" fields have been removed from the typeIndexService proposal. The filters for the typeIndexService are, therefore, no longer needed and have been removed. The POST operation on typeIndexService no longer made any sense and has been removed. The typeSearchService, because multiple filters can be added, can be used for finding both lws:Containers and/or lws:DataResource with pagination being handled. Other text clarifications made.

elf-pavlik · 2026-04-05T00:35:17Z

How does this proposal address sharing resources via Capability URLs?
Some resources will be have public read permission but they should not appear in an index readable by the public.

Co-authored-by: Aaron Coburn <aaronc@inrupt.com>

gibsonf1 · 2026-06-08T12:49:06Z


+<section id="type-index-services">
+  <h3>Search and Type Index Services</h3>
+  <p>The <code>TypeIndexService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource URIs matching those types.


This should be named SearchService as it already searches for things other than types.

Do you mean?

Suggested change

<p>The <code>TypeIndexService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource URIs matching those types.

<p>The <code>TypeIndexService</code> provides a server-managed discovery

mechanism to query the distinct resource types available within a storage,

while the <code>SearchService</code> allows clients to retrieve the specific

resource URIs matching those types.

gibsonf1 · 2026-06-08T12:50:32Z

+<p>
+To prevent inadvertent or malicious corruption by clients, these services are strictly populated and managed by the server. To mitigate security and performance risks associated with deep-parsing arbitrary resource bodies, servers are not required to parse resource content to discover types. Instead, servers SHOULD derive resource types from HTTP Link headers provided by the client during resource creation or modification, combined with the server's intrinsic knowledge of the resource's state (such as native LWS classes like <code>https://www.w3.org/ns/lws#Container</code>).
+  </p><p>
+Servers MAY additionally derive types from the resource representation itself when they are able to parse it. Implementations are encouraged to do so where feasible, as richer type discovery improves the utility of the Type Index and Type Search services. When a server enriches the type index from resource content, the types it surfaces MUST be treated identically to those derived from Link headers for the purposes of indexing, search, and authorization filtering.


-Type "Search Service"

Do you mean?

Suggested change

Servers MAY additionally derive types from the resource representation itself when they are able to parse it. Implementations are encouraged to do so where feasible, as richer type discovery improves the utility of the Type Index and Type Search services. When a server enriches the type index from resource content, the types it surfaces MUST be treated identically to those derived from Link headers for the purposes of indexing, search, and authorization filtering.

Servers MAY additionally derive types from the resource representation itself

when they are able to parse it. Implementations are encouraged to do so where

feasible, as richer type discovery improves the utility of the Type Index and

Search services. When a server enriches the type index from resource content,

the types it surfaces MUST be treated identically to those derived from Link

headers for the purposes of indexing, searching, and authorization filtering.

gibsonf1 · 2026-06-08T12:51:45Z

+  </section>
+
+  <section>
+    <h4>GET [TypeSearchService]</h4>


-Type "SearchService"

Do you mean?

Suggested change

<h4>GET [TypeSearchService]</h4>

<h4>GET [SearchService]</h4>

gibsonf1 · 2026-06-08T12:52:17Z

+    </p>
+    <p>
+      The <code>type</code> parameter is the mandatory baseline and MUST be supported by every server that implements the
+      <code>TypeSearchService</code>. A server MAY additionally index other <em>descriptive</em> link


-Type "SearchService"

Do you mean?

Suggested change

<code>TypeSearchService</code>. A server MAY additionally index other <em>descriptive</em> link

<code>SearchService</code>. A server MAY additionally index other <em>descriptive</em> link

gibsonf1 · 2026-06-08T12:52:53Z

+    </p>
+    <p class="note">Clients MUST URL-encode query parameter keys and values.</p>
+    <p>Returns <code>application/lws+json</code>: A paginated <code>ContainerPage</code> whose items describe the matching LWS resources. Aside from <code>type</code> and any additional relation parameters described above, no other parameters are defined.</p>
+    <p class="note">A <code>ContainerPage</code> returned by the <code>TypeSearchService</code> is a <em>synthetic</em> result set, not a representation of a container resource. The <code>ContainerPage</code> media type and pagination model are reused only for client convenience; the response does not identify a container, has no containment relationship to its members, is not retrievable or mutable as a resource, and its membership reflects the query rather than any stored hierarchy. Each item is a resource description carrying at least <code>id</code> and <code>type</code>, mirroring a container member; a server MAY include additional descriptive metadata (such as <code>mediaType</code>, <code>size</code>, or <code>modified</code>) but is not required to. The same applies to the <code>POST</code> form.</p>


-Type "SearchService"

Do you mean?

Suggested change

<p class="note">A <code>ContainerPage</code> returned by the <code>TypeSearchService</code> is a <em>synthetic</em> result set, not a representation of a container resource. The <code>ContainerPage</code> media type and pagination model are reused only for client convenience; the response does not identify a container, has no containment relationship to its members, is not retrievable or mutable as a resource, and its membership reflects the query rather than any stored hierarchy. Each item is a resource description carrying at least <code>id</code> and <code>type</code>, mirroring a container member; a server MAY include additional descriptive metadata (such as <code>mediaType</code>, <code>size</code>, or <code>modified</code>) but is not required to. The same applies to the <code>POST</code> form.</p>

<p class="note">A <code>ContainerPage</code> returned by the

<code>SearchService</code> is a <em>synthetic</em> result set, not a

representation of a container resource. The <code>ContainerPage</code>

media type and pagination model are reused only for client convenience;

the response does not identify a container, has no containment relationship

to its members, is not retrievable or mutable as a resource, and its

membership reflects the query rather than any stored hierarchy. Each item

is a resource description carrying at least <code>id</code> and

<code>type</code>, mirroring a container member; a server MAY include

additional descriptive metadata (such as <code>mediaType</code>,

<code>size</code>, or <code>modified</code>) but is not required to. The

same applies to the <code>POST</code> form.</p>

gibsonf1 · 2026-06-08T12:53:13Z

+  </section>
+
+  <section>
+    <h4>POST [TypeSearchService]</h4>


-Type "SearchService"

Do you mean?

Suggested change

<h4>POST [TypeSearchService]</h4>

<h4>POST [SearchService]</h4>

gibsonf1 · 2026-06-08T12:53:54Z

+  <section>
+    <h4>Request Equivalence and Errors</h4>
+    <p>
+      A server implementing the <code>TypeSearchService</code> MUST support both the <code>GET</code> and


-Type "SearchService"

Do you mean?

Suggested change

A server implementing the <code>TypeSearchService</code> MUST support both the <code>GET</code> and

A server implementing the <code>SearchService</code> MUST support both the <code>GET</code> and

gibsonf1 · 2026-06-08T12:54:35Z

+  <section>
+    <h4>Security and Authorization</h4>
+    <p>
+      Servers MUST enforce authorization. Responses to GET/POST on <code>TypeIndexService</code> or <code>TypeSearchService</code> include only types and resource URIs that the authenticated client is explicitly authorized to read. 


-Type "SearchService"

Do you mean?

Suggested change

Servers MUST enforce authorization. Responses to GET/POST on <code>TypeIndexService</code> or <code>TypeSearchService</code> include only types and resource URIs that the authenticated client is explicitly authorized to read.

Servers MUST enforce authorization. Responses to GET/POST on

<code>TypeIndexService</code> or <code>SearchService</code> include

only types and resource URIs that the authenticated client is

explicitly authorized to read.

gibsonf1 · 2026-06-08T12:55:27Z

+
+    <pre class="example" title="GET Search for Instances (Using DataResource filter)">
+Request
+GET /types/search?type=https://schema.org/Person&amp;type=https://www.w3.org/ns/lws%23DataResource


GET /search?

Do you mean?

Suggested change

GET /types/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource

GET /search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource

gibsonf1 · 2026-06-08T12:55:56Z

+Response
+HTTP/1.1 200 OK
+Content-Type: application/lws+json
+Link: &lt;https://example.org/types/search?type=https://schema.org/Person&amp;type=https://www.w3.org/ns/lws%23DataResource&amp;page=1&gt;; rel="first"


Link: <https://example.org/search?

Do you mean?

Suggested change

Link: <https://example.org/types/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=1>; rel="first"

Link: <https://example.org/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=1>; rel="first"

gibsonf1 · 2026-06-08T12:56:14Z

+HTTP/1.1 200 OK
+Content-Type: application/lws+json
+Link: &lt;https://example.org/types/search?type=https://schema.org/Person&amp;type=https://www.w3.org/ns/lws%23DataResource&amp;page=1&gt;; rel="first"
+Link: &lt;https://example.org/types/search?type=https://schema.org/Person&amp;type=https://www.w3.org/ns/lws%23DataResource&amp;page=2&gt;; rel="next"


Link: <https://example.org/search?

Do you mean?

Suggested change

Link: <https://example.org/types/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=2>; rel="next"

Link: <https://example.org/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=2>; rel="next"

gibsonf1 · 2026-06-08T12:56:43Z

+
+    <pre class="example" title="GET Search for container resources (is-a)">
+Request
+GET /types/search?type=https://www.w3.org/ns/lws%23Container


GET /search?type=https://www.w3.org/ns/lws%23Container

Do you mean?

Suggested change

GET /types/search?type=https://www.w3.org/ns/lws%23Container

GET /search?type=https://www.w3.org/ns/lws%23Container

gibsonf1 · 2026-06-08T12:57:12Z

+
+    <pre class="example" title="POST Search with Multiple Type Filters">
+Request
+POST /types/search


POST /search

Do you mean?

Suggested change

POST /types/search

POST /search

gibsonf1 · 2026-06-08T12:57:37Z

+
+    <pre class="example" title="CNF Filter (OR within a group, AND across groups)">
+Request (GET form: comma = OR, repeated parameter = AND)
+GET /types/search?type=https://schema.org/Person,http://xmlns.com/foaf/0.1/Person&amp;type=https://www.w3.org/ns/lws%23DataResource


GET /search?

Do you mean?

Suggested change

GET /types/search?type=https://schema.org/Person,http://xmlns.com/foaf/0.1/Person&type=https://www.w3.org/ns/lws%23DataResource

GET /search?type=https://schema.org/Person,http://xmlns.com/foaf/0.1/Person&type=https://www.w3.org/ns/lws%23DataResource

gibsonf1 · 2026-06-08T12:57:53Z

+GET /types/search?type=https://schema.org/Person,http://xmlns.com/foaf/0.1/Person&amp;type=https://www.w3.org/ns/lws%23DataResource
+
+Equivalent Request (POST form: nested array = OR group, outer array = AND)
+POST /types/search


POST /search

Do you mean?

Suggested change

POST /types/search

POST /search

gibsonf1 · 2026-06-08T12:58:17Z

+
+    <pre class="example" title="Filtering on an indexed relation (describedby)">
+Request (GET: type AND a 'describedby' relation; relation name used as the parameter)
+GET /types/search?type=https://schema.org/Person&amp;describedby=https://shapes.example/PersonShape


GET /search?

Do you mean?

Suggested change

GET /types/search?type=https://schema.org/Person&describedby=https://shapes.example/PersonShape

GET /search?type=https://schema.org/Person&describedby=https://shapes.example/PersonShape

gibsonf1 · 2026-06-08T12:58:31Z

+GET /types/search?type=https://schema.org/Person&amp;describedby=https://shapes.example/PersonShape
+
+Equivalent Request (POST)
+POST /types/search


POST /search

Do you mean?

Suggested change

POST /types/search

POST /search

gibsonf1 · 2026-06-08T13:01:12Z


+<section id="type-index-services">
+  <h3>Search and Type Index Services</h3>
+  <p>The <code>TypeIndexService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource URIs matching those types.


...SearchService allows clients to search on resources including matching on indexed types.

Do you mean?

Suggested change

<p>The <code>TypeIndexService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource URIs matching those types.

<p>The <code>TypeIndexService</code> provides a server-managed discovery mechanism

to query the distinct resource types available within a storage, while the

<code>SearchService</code> allows clients to search on resources including

matching on indexed types.

gibsonf1 · 2026-06-08T13:05:14Z

+      "serviceEndpoint": "https://example.org/types/index"
+    },
+    {
+      "type": "TypeSearchService",


-Type "SearchService"

Do you mean this?

Suggested change

"type": "TypeSearchService",

"type": "SearchService",

gibsonf1 · 2026-06-08T13:05:46Z

+    },
+    {
+      "type": "TypeSearchService",
+      "serviceEndpoint": "https://example.org/types/search"


"serviceEndpoint": "https://example.org/search"

Do you mean this?

Suggested change

"serviceEndpoint": "https://example.org/types/search"

"serviceEndpoint": "https://example.org/search"

elf-pavlik · 2026-06-08T13:37:05Z

@gibsonf1 specific url for the serviceEndpoint in Storage Description can and most likely will be different for every server, that's why it needs to be discovered. https://pr-preview.s3.amazonaws.com/w3c/lws-protocol/pull/115.html

Once WG agrees on using different naming than TypeIndex / TypeSearch snippets can be updated accordingly

elf-pavlik

I think it still needs few iterations after this PR is merged.
Keeping track on related use cases and requirements. Security and Authorization section is addressing requirements from this Use Case, which I submitted:

w3c/lws-ucs#222

acoburn

June 8, 2026, WG meeting approved this PR for merging

ebremer changed the title ~~add Type Index text~~ add Type Index Section Mar 30, 2026

ebremer force-pushed the typeIndex branch from f30e85b to 1f6d19c Compare March 30, 2026 19:45

add Type Index text

79f3fa1

ebremer force-pushed the typeIndex branch from 912b4dc to 79f3fa1 Compare March 30, 2026 20:07

elf-pavlik reviewed Mar 31, 2026

View reviewed changes

ebremer added 8 commits April 2, 2026 10:09

make clarifications for fields

88e4be3

remove "default" field add search endpoint to Storage description

clean up text

926018d

reworked. location removed from [typeIndexService]. Containers or

f5e57d1

instances can be found with [typeSearchService]

remove filter from [typeIndexService]

a0f9e0a

remove POST in [typeIndexService]

ad22e84

remove type filter in [typeIndexService]

67adbe2

clairify text

353e5e0

remove uuencoding on examples for readability

8e3413f

ebremer added 2 commits April 3, 2026 14:08

remove property filter

5c0f86f

clarify text

b862890

ebremer force-pushed the typeIndex branch from 233787b to b862890 Compare April 3, 2026 18:50

elf-pavlik mentioned this pull request Apr 4, 2026

Add editors draft for LWS Access Requests and Access Grants #106

Merged

gibsonf1 reviewed Apr 8, 2026

View reviewed changes

Comment thread lws10-core/Discovery.html Outdated

gibsonf1 reviewed Apr 8, 2026

View reviewed changes

Comment thread lws10-core/Discovery.html Outdated

elf-pavlik reviewed Apr 13, 2026

View reviewed changes

Comment thread lws10-core/Discovery.html Outdated

ebremer added 4 commits April 15, 2026 14:07

soften language on how types are populated into the index

a9c5504

reverse order

f551b6a

fix storage description for typeSearch and typeIndex

8859fd0

formatting

5c115d6

Update lws10-core/Discovery.html

69797ca

Co-authored-by: Aaron Coburn <aaronc@inrupt.com>

gibsonf1 reviewed Jun 8, 2026

View reviewed changes

elf-pavlik approved these changes Jun 8, 2026

View reviewed changes

elf-pavlik mentioned this pull request Jun 8, 2026

add Implementations.md #171

Open

ebremer added 2 commits June 12, 2026 13:43

Merge branch 'main' into typeIndex

a61f22a

move Search and Type Index Services into separate document

573b48a

ebremer force-pushed the typeIndex branch from f8cf961 to 573b48a Compare June 12, 2026 19:08

acoburn approved these changes Jun 15, 2026

View reviewed changes

ebremer merged commit d21edb0 into main Jun 15, 2026
2 checks passed

ebremer deleted the typeIndex branch June 15, 2026 13:40

	<h4>GET [TypeSearchService]</h4>
	<h4>GET [SearchService]</h4>

	<code>TypeSearchService</code>. A server MAY additionally index other <em>descriptive</em> link
	<code>SearchService</code>. A server MAY additionally index other <em>descriptive</em> link

	<h4>POST [TypeSearchService]</h4>
	<h4>POST [SearchService]</h4>

	A server implementing the <code>TypeSearchService</code> MUST support both the <code>GET</code> and
	A server implementing the <code>SearchService</code> MUST support both the <code>GET</code> and

	GET /types/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource
	GET /search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource

	Link: <https://example.org/types/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=1>; rel="first"
	Link: <https://example.org/search?type=https://schema.org/Person&type=https://www.w3.org/ns/lws%23DataResource&page=1>; rel="first"

	GET /types/search?type=https://www.w3.org/ns/lws%23Container
	GET /search?type=https://www.w3.org/ns/lws%23Container

Conversation

ebremer commented Mar 30, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acoburn commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gibsonf1 commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gibsonf1 Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gibsonf1 Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gibsonf1 commented Apr 1, 2026

Uh oh!

ebremer commented Apr 2, 2026

Uh oh!

elf-pavlik commented Apr 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ebremer commented Mar 30, 2026 •

edited by pr-preview Bot

Loading

acoburn commented Mar 30, 2026 •

edited

Loading

gibsonf1 commented Mar 30, 2026 •

edited

Loading

gibsonf1 Mar 31, 2026 •

edited

Loading

gibsonf1 Mar 31, 2026 •

edited

Loading

TallTed Jun 9, 2026 •

edited

Loading