feat: support `M.raw()` in method guards by michaelfig · Pull Request #1831 · endojs/endo

michaelfig · 2023-10-12T18:04:58Z

closes: #1725 closes: #1772
refs: #1724

Description

Complete the #1724 experiment, as well as using the defaultGuards option (originally discussed in #1725 (comment)) instead of boolean flags for sloppy and raw.

Security Considerations

The new M.raw() guard is only honoured by arguments and return values in defendSyncMethod, so it should not leak elsewhere as a pattern.

Scaling Considerations

Some additional overhead in redacting raw arguments (in defendSyncArgs), but work is minimized by calculating relevant data structures while wrapping methods before any exos are created (in defendSyncMethod).

Documentation Considerations

Testing Considerations

Upgrade Considerations

Backward compatibility is implemented for interfaceGuards created using the legacy sloppy parameter.

erights

Looks great! But the klass: '...' issue must first be fixed. See the AwaitArgGuard as an example guide.

packages/exo/src/exo-tools.js

erights · 2023-10-14T00:32:46Z

packages/patterns/src/patterns/patternMatchers.js

    interfaceName: M.string(),
    methodGuards: M.recordOf(M.string(), MethodGuardShape),
-    sloppy: M.boolean(),
+    defaultGuards: M.or('never', 'passable', 'raw'),


Since this property is new, consider whether it should be moved into the optional part of this splitRecord pattern. But if you are confident we don't need to, then don't.

Thanks, I reintroduced sloppy and moved defaultGuards down to remain compatible.

Actually, you introduced defaultGuards in the mandatory section. If we get away with that, then we know this new code never encounters any InterfaceGuardPayloads created by code before this PR. That's great! If we believe that, then I think you can simply delete the optional sloppy: below. Otherwise, I think both sloppy: and defaultGuards: need to go into the optional section.

I think we need both sloppy and defaultGuards in the optional section.

packages/patterns/src/patterns/patternMatchers.js

packages/patterns/src/types.js

packages/exo/test/test-heap-classes.js

michaelfig · 2023-10-27T03:30:13Z

All comments are addressed, and CI is passing. Ready for rereview!

packages/exo/src/exo-makers.js

packages/exo/src/exo-tools.js

gibson042

Even reading the linked issues, I'm not clear on the motivation for introducing this non-Passable "raw" argument/return and unknown-method functionality, and am wondering if it might be better to instead establish a convention for e.g. conveying mutable objects via thunks and/or introduce specific configuration for supporting unknown methods. Can you explain the need?

gibson042 · 2023-10-27T16:22:34Z

packages/exo/src/exo-makers.js

 * }> | undefined} interfaceGuard
 * @param {I} init
- * @param {M & ThisType<{ self: M, state: ReturnType<I> }>} methods
+ * @param {M & ThisType<{ self: Facet<M>, state: ReturnType<I> }>} methods


https://github.com/Agoric/agoric-sdk/blob/master/packages/SwingSet/docs/virtual-objects.md draws a distinction between an exo object (therein a "VDO") and a facet, so self: Facet<M> seems wrong. I think the "Facet" type should be renamed accordingly, perhaps to something like "Guarded"?

gibson042 · 2023-10-27T16:56:05Z

packages/exo/src/exo-tools.js

+const defendSyncArgs = (syncArgs, redactConfig, label = undefined) => {
+  const {
+    declaredLen,
+    hasRestArgGuard,
+    paramsPattern,
+    rawRestArgs,
+    redactedIndices,
+  } = redactConfig;


Clarifying suggestion (but note that at this point I am not clear on the specifics of what "redaction" is doing here at all):

Suggested change

const defendSyncArgs = (syncArgs, redactConfig, label = undefined) => {

const {

declaredLen,

hasRestArgGuard,

paramsPattern,

rawRestArgs,

redactedIndices,

} = redactConfig;

const defendSyncArgs = (syncArgs, redactionConfig, label = undefined) => {

const {

declaredLen,

hasRestArgGuard,

paramsPattern,

rawRestArgs,

redactedIndices,

} = redactionConfig;

gibson042 · 2023-10-27T17:01:57Z

packages/exo/src/exo-tools.js

+  let redactedArgs = syncArgs;
+  if (rawRestArgs) {
+    // Don't harden the rest args.
+    redactedArgs = syncArgs.slice(0, Math.min(syncArgs.length, declaredLen));


I don't think this Math.min is doing anything; slice already clamps its second argument to the length of the array.

Suggested change

redactedArgs = syncArgs.slice(0, Math.min(syncArgs.length, declaredLen));

redactedArgs = syncArgs.slice(0, declaredLen);

gibson042 · 2023-10-27T17:12:15Z

packages/exo/src/exo-tools.js

+    redactedArgs[i] = REDACTED_RAW_ARG;
+  }
+
+  mustMatch(harden(redactedArgs), paramsPattern, label);


The redactedArgs name seems a little misleading, implying e.g. "those arguments that have been redacted". Maybe instead matchableArgs?

Also, I question the value of completely ignoring raw rest args here—it's probably better to preserve their presence:

// Use syncArgs if possible, but copy it when necessary to implement redactions. let matchableArgs = syncArgs; if (rawRestArgs && syncArgs.length > declaredLen) { const restLen = syncArgs.length - declaredLen; const redactedRest = Array(restLen).fill(REDACTED_RAW_ARG); matchableArgs = [...syncArgs.slice(0, declaredLen), ...redactedRest]; } else if (redactedIndices.length > 0 && redactedIndices[0] < syncArgs.length) { matchableArgs = [...syncArgs]; } for (const i of redactedIndices) { if (i >= matchableArgs.length) { break; } matchableArgs[i] = REDACTED_RAW_ARG; } mustMatch(harden(redactedArgs), paramsPattern, label);

packages/exo/src/exo-tools.js

gibson042 · 2023-10-27T17:39:06Z

packages/exo/src/exo-tools.js

+  let rawRestArgGuard = restArgGuard;
+  let rawRestArgs = false;
+  if (isRawGuard(rawRestArgGuard)) {
+    rawRestArgGuard = undefined;


Suggested change

rawRestArgGuard = undefined;

rawRestArgGuard = REDACTED_RAW_ARG;

This needed some finessing, after replacing undefined with the only pattern that could possibly work: M.arrayOf(REDACTED_RAW_ARG).

Ah, better yet then:

Suggested change

rawRestArgGuard = undefined;

matchableRestArgGuard = M.any();

If we're going through the effort to create rest arguments that are each REDACTED_RAW_ARG, I'd rather do the stricter arrayOf pattern. Without being strict, I see no compelling reason to do anything other than just drop raw rest arguments rather than doing this whole match-but-bypass dance.

gibson042 · 2023-10-27T17:43:40Z

packages/exo/src/exo-tools.js

 const defendSyncMethod = (method, methodGuardPayload, label) => {
  const { returnGuard } = methodGuardPayload;
+  const isRawReturn = isRawGuard(returnGuard);
+  const redactConfig = redactRawArgs(methodGuardPayload);


Suggested change

const redactConfig = redactRawArgs(methodGuardPayload);

const redactionConfig = toRedactionConfig(methodGuardPayload);

gibson042 · 2023-10-27T17:57:47Z

packages/patterns/src/types.js

+ * @property {() => RawGuard} raw
+ * In parameter position, pass this argument through without any hardening or checking.
+ * In rest position, pass the rest of the arguments through without any hardening or checking.
+ * In return position, return the result without any hardening or ßchecking.


Suggested change

* In return position, return the result without any hardening or ßchecking.

* In return position, return the result without any hardening or checking.

michaelfig · 2023-10-27T19:55:30Z

Even reading the linked issues, I'm not clear on the motivation for introducing this non-Passable "raw" argument/return

Exos used to be tightly coupled to @endo/pass-style, so that it was impossible to define an exo method that either took a non-Passable as an argument or returned a non-Passable. The usage I am working towards is an exo-promise that allows settler.resolve(anyValueAtAll). There is no way to express such a method on an exo class, since the old most lenient argument guard (M.any()) was to harden(anyValueAtAll) and then assert it was passable.

and unknown-method functionality,

We already had the unknown-method functionality called sloppy, and @erights proposed extending it to allow the specification of sloppy-passable methods, as well as sloppy-raw methods. I did the implementation in this PR, even though I have no particular use for the functionality at this point, and prefer the "raw" argument/return annotations since they are stricter.

and am wondering if it might be better to instead establish a convention

I want to be able to create exo objects or facets whose methods can be just as flexible as a vanilla JS function, but have that be an opt-out so that the Exo model of guards and patterns is the default behaviour.

for e.g. conveying mutable objects via thinks

Funny you should mention that. Thunks are non-passable, too!

and/or introduce specific configuration for supporting unknown methods.

The specific configuration is to explicitly specify M.interface('Foo', { meth: M.call().rest(M.raw()).returns(M.raw()) }). Arguably, we could lean in further and do something like M.interface('Foo', { meth: M.callRaw() }) too.

Can you explain the need?

I don't want to make breaking design changes to contracts or libraries that I'm converting to be Exo-objects. Especially when so much of their behaviour fits into the Exo-object model already. M.raw() makes that possible. The unknown method support is tangential but related, and I don't really care as much about it.

erights · 2023-10-27T22:20:48Z

packages/exo/src/exo-makers.js

+// Used in typing.
+GET_INTERFACE_GUARD;


What does this no-effect statement do?

erights · 2023-10-27T22:24:28Z

packages/exo/src/exo-makers.js

-    /** @type {KitContext<ReturnType<I>,F>} */
-    const context = { state, facets: {} };
+    /** @type {{ state: ReturnType<I>, facets: unknown }} */
+    const context = { state, facets: null };


Why is null here correct? The original

Suggested change

const context = { state, facets: null };

const context = { state, facets: {} };

seems more correct.

I intended for the null to make it explicit that facets is not yet initialized. I could have used undefined instead, but I think {} implies that the identity will be kept intact (which it isn't). The code below replaces it with the actual facets object.

erights

LGTM!

But especially curious about facets: null. Am I missing something?

gibson042 · 2023-10-28T14:47:04Z

Even reading the linked issues, I'm not clear on the motivation for introducing this non-Passable "raw" argument/return

Exos used to be tightly coupled to @endo/pass-style, so that it was impossible to define an exo method that either took a non-Passable as an argument or returned a non-Passable. The usage I am working towards is an exo-promise that allows settler.resolve(anyValueAtAll). There is no way to express such a method on an exo class, since the old most lenient argument guard (M.any()) was to harden(anyValueAtAll) and then assert it was passable.

I think that just pushes the question back a level... what is the underlying motivation for non-Passable promise resolution? M.raw() seems like a reasonable way to get a pattern representing literally any value, and defaultGuards "passable" vs. "raw" seems good for its propagation through defineExo{Class,ClassKit}, but I'm still wondering why we need to do anything at all here.

for e.g. conveying mutable objects via thinks

Funny you should mention that. Thunks are non-passable, too!

Are they?

import "@endo/init";
import { Far } from "@endo/far";
import { M, matches } from "@endo/patterns";

const fn = Far("fn", () => "returned");
fn();
// => "returned"
matches(fn, M.remotable());
// => true

I don't want to make breaking design changes to contracts or libraries that I'm converting to be Exo-objects.

Ah, this seems like it's heading in the direction I care about. What is being converted to exo, what is the benefit, and how do they currently interact with non-Passable values?

gibson042 · 2023-10-28T14:47:11Z

packages/patterns/src/types.js

 */

+/**
+ * @typedef {'never' | 'passable' | 'raw'} DefaultGuardType


Why allow "never"? I think we would normally use undefined to indicate an unchanged default, and certainly not a word that could be misinterpreted as meaning something like "even less than raw".

Suggested change

* @typedef {'never' | 'passable' | 'raw'} DefaultGuardType

* @typedef {undefined | 'passable' | 'raw'} DefaultGuardType

gibson042 · 2023-10-28T15:24:53Z

packages/exo/src/exo-makers.js

 const LABEL_INSTANCES = DEBUG.split(',').includes('label-instances');

+/**
+ * @template {{}} T


Clarity/repository consistency nit:

Suggested change

* @template {{}} T

* @template {object} T

(details)

$ patt='[{]([{][}]|object)[}]' $ git grep -liE "$patt" packages/ | xargs grep --no-filename -oE "$patt" | sort | uniq -c 9 {{}} 187 {object}

They are not the same. Object.create(proto) is a type error unless proto extends {}.

gibson042 · 2023-10-28T15:26:37Z

packages/patterns/src/types.js


-/** @typedef {AwaitArgGuard | Pattern} ArgGuard */
+/**
+ * @typedef {{}} RawGuardPayload


Suggested change

* @typedef {{}} RawGuardPayload

* @typedef {object} RawGuardPayload

This time, I'm specifying that RawGuardPayload is the empty object, not just anything of type object.

gibson042 · 2023-10-28T16:43:00Z

packages/exo/src/exo-tools.js

+  let rawRestArgGuard = restArgGuard;
+  let rawRestArgs = false;
+  if (isRawGuard(rawRestArgGuard)) {
+    rawRestArgGuard = undefined;


Ah, better yet then:

Suggested change

rawRestArgGuard = undefined;

matchableRestArgGuard = M.any();

gibson042 · 2023-10-28T16:59:45Z

packages/patterns/src/types.js

 *   interfaceName: string,
 *   methodGuards: any,
- *   options: {sloppy: true}) => InterfaceGuard<Record<PropertyKey, MethodGuard>>
+ *   options: {defaultGuards?: 'passable' | 'raw', sloppy?: true }) => InterfaceGuard<any>


With the above suggestion to replace "never" with undefined, this could also be simplified.

Suggested change

* options: {defaultGuards?: 'passable' | 'raw', sloppy?: true }) => InterfaceGuard<any>

* options: {defaultGuards?: DefaultGuardType, sloppy?: true }) => InterfaceGuard<any>

Can't really simplify, because it has special meaning as a function overload.

gibson042 · 2023-10-28T17:19:37Z

packages/patterns/src/types.js

+ * In parameter position, guard a parameter by awaiting it. Can only be used in
+ * parameter position of an `M.callWhen`.
+ * `M.await(M.nat())`, for example, with `await` the corresponding argument,
+ * check that the fulfillment of the `await` satisfies the `M.nat()`
+ * pattern, and only then proceed to call the raw method with that fulfillment.
+ * If the argument already passes the `M.nat()` pattern, then the result of
+ * `await`ing it will still pass, and the `M.callWhen` will still delay the
+ * raw method call to a future turn.
+ * If the argument is a promise that rejects rather than fulfills, or if its
+ * fulfillment does not satisfy the nested pattern, then the call is rejected
+ * without ever calling the raw method.


👍 👍 for adding this.

Suggested change

* In parameter position, guard a parameter by awaiting it. Can only be used in

* parameter position of an `M.callWhen`.

* `M.await(M.nat())`, for example, with `await` the corresponding argument,

* check that the fulfillment of the `await` satisfies the `M.nat()`

* pattern, and only then proceed to call the raw method with that fulfillment.

* If the argument already passes the `M.nat()` pattern, then the result of

* `await`ing it will still pass, and the `M.callWhen` will still delay the

* raw method call to a future turn.

* If the argument is a promise that rejects rather than fulfills, or if its

* fulfillment does not satisfy the nested pattern, then the call is rejected

* without ever calling the raw method.

* Guard a positional parameter in `M.callWhen`, awaiting it and matching its

* fulfillment against the provided pattern.

* For example, `M.callWhen(M.await(M.nat())).returns()` will await the first

* argument, check that its fulfillment satisfies `M.nat()`, and only then call

* the guarded method with that fulfillment. If the argument is a non-promise

* value that already satisfies `M.nat()`, then the result of `await`ing it will

* still pass, and `M.callWhen` will still delay the guarded method call to a

* future turn.

* If the argument is a promise that rejects rather than fulfills, or if its

* fulfillment does not satisfy the nested pattern, then the call is rejected

* without ever invoking the guarded method.

Credit to @erights for the addition. I just cherry-picked it. 😊

gibson042 · 2023-10-28T17:50:20Z

packages/patterns/src/types.js

- * @property {(rArgGuard: Pattern) => MethodGuardMaker2} rest
- * @property {(returnGuard?: Pattern) => MethodGuard} returns
+ * @property {(restArgGuard: SyncValueGuard) => MethodGuardMaker2} rest
+ * If the rest argument guard is not `M.raw()`, all rest arguments are
+ * automatically hardened and must be Passable.
+ * @property {(returnGuard?: SyncValueGuard) => MethodGuard} returns
+ * If the return guard is not `M.raw()`, the return value is automatically
+ * hardened and must be Passable.


Is it possible to define these types in a way that doesn't require so much repetition?

/** * @typedef {MethodGuardOptMaker & MethodGuardRestMaker & MethodGuardFinalizer} MethodGuardMaker * A method name and parameter/return signature like: * ```js * foo(a, b, c = d, ...e) => f * ``` * should be guarded by something like: * ```js * { * ...otherMethodGuards, * foo: M.call(AShape, BShape).optional(CShape).rest(EShape).returns(FShape), * } * ``` */ /** * @typedef {object} MethodGuardOptMaker * @property {(...optArgGuards: ArgGuard[]) => (MethodGuardRestMaker & MethodGuardFinalizer)} optional * Optional arguments not guarded with `M.raw()` are automatically hardened and * must be Passable. */ /** * @typedef {object} MethodGuardRestMaker * @property {(restArgGuard: SyncValueGuard) => MethodGuardFinalizer} rest * If the rest argument guard is not `M.raw()`, all rest arguments are * automatically hardened and must be Passable. */ /** * @typedef {object} MethodGuardFinalizer * @property {(returnGuard?: SyncValueGuard) => MethodGuard} returns * If the return guard is not `M.raw()`, the return value is automatically * hardened and must be Passable. */

Thanks, I like that! Usually, my DRY factor is 2, but I am more lenient sometimes when I haven't seen the best way to factor.

michaelfig · 2023-10-29T02:38:21Z

const fn = Far("fn", () => "returned");
fn();
// => "returned"
matches(fn, M.remotable());
// => true

Oh, I misspoke when I said "thunks are non-passable". I meant to say "passable thunks are not consistently supported in SwingSet and other random parts of our system, so I wouldn't count on using them for anything important until they have had significantly more testing."

Ah, this seems like it's heading in the direction I care about. What is being converted to exo, what is the benefit, and how do they currently interact with non-Passable values?

IBC/Network vats and Pegasus are being made durable and upgradable. I'm trying to do a minimal implementation of upgrade-tolerant promise-like remotables, and that's the last in a long line of trying to do promise-like remotables and bashing my head into the ceiling imposed by the passable restrictions. This PR is the result of trying to raise that ceiling so that I can use Zones and Exo-objects for durability as advertised.

Refs: #1831, Agoric/agoric-sdk#11931 ## Description We wish to visibly deprecate the `sloppy` option of `@endo/patterns` interface guards. To avoid an explosion of `@typedef` blocks, we migrate the `@endo/patterns` types to TypeScript and then add the minimally required `@deprecated` tags. ### Security Considerations N/A ### Scaling Considerations N/A ### Documentation Considerations N/A ### Testing Considerations This modifies the implementation of the `@endo/patterns` types, but should not modify them. Since the number of lines changed is larged, we should attempt to convince ourselves that the types are in fact the same. ### Compatibility Considerations N/A ### Upgrade Considerations Deprecates but does not remove the `sloppy` option. `NEWS.md` is updated.

michaelfig force-pushed the mfig-interface-optout branch 4 times, most recently from 369921f to afc3670 Compare October 13, 2023 17:12

michaelfig requested a review from erights October 13, 2023 17:28

michaelfig marked this pull request as ready for review October 13, 2023 17:28

michaelfig force-pushed the mfig-interface-optout branch from afc3670 to cb4a38d Compare October 13, 2023 17:32

michaelfig requested a review from turadg October 13, 2023 17:32

erights requested changes Oct 14, 2023

View reviewed changes

turadg reviewed Oct 16, 2023

View reviewed changes

packages/exo/test/test-heap-classes.js Outdated Show resolved Hide resolved

michaelfig force-pushed the mfig-interface-optout branch from cb4a38d to fe8ad36 Compare October 18, 2023 03:33

michaelfig changed the title ~~feat: support M.rawValue() in method guards~~ feat: support M.raw() in method guards Oct 23, 2023

erights and others added 2 commits October 26, 2023 11:20

feat(exo): opt out individual arguments

bf593d8

feat(defaultGuards): absorb sloppy and raw

58a3d42

michaelfig force-pushed the mfig-interface-optout branch from fe8ad36 to 7ba22ea Compare October 27, 2023 01:24

michaelfig requested review from erights and turadg October 27, 2023 01:29

michaelfig force-pushed the mfig-interface-optout branch 2 times, most recently from 2f707d0 to 263254a Compare October 27, 2023 03:23

turadg reviewed Oct 27, 2023

View reviewed changes

michaelfig force-pushed the mfig-interface-optout branch from 263254a to 186711b Compare October 27, 2023 16:47

gibson042 reviewed Oct 27, 2023

View reviewed changes

michaelfig requested a review from gibson042 October 27, 2023 19:57

erights reviewed Oct 27, 2023

View reviewed changes

erights approved these changes Oct 28, 2023

View reviewed changes

gibson042 approved these changes Oct 28, 2023

View reviewed changes

michaelfig added 8 commits October 28, 2023 22:49

feat(defendSyncMethod): implement raw exo methods

c8126dc

fix(exo): tighten typing

c50ee18

fix(patterns): M.rawValue() -> M.raw()

5b94530

test(exo): test explicit M.raw()

12624f5

docs(patterns): describe M.raw() vs call and callWhen

22bd9c3

refactor(exo): break GET_INTERFACE_GUARD loop

df16978

fix(patterns): remove defaultGuards: 'never' for undefined

77d04b2

docs(patterns): dedupe the MethodGuardMaker types

a0b3a5c

michaelfig force-pushed the mfig-interface-optout branch from 7c1fc7a to a0b3a5c Compare October 29, 2023 04:49

michaelfig enabled auto-merge October 29, 2023 04:50

michaelfig merged commit 746974b into master Oct 29, 2023

michaelfig deleted the mfig-interface-optout branch October 29, 2023 04:58

erights mentioned this pull request Oct 29, 2023

fix(exo): allow richer behaviorMethods #1809

Merged

michaelfig mentioned this pull request Nov 10, 2023

fix(exo): update M.callWhen broken by M.raw() #1859

Merged

rekmarks mentioned this pull request Sep 16, 2025

refactor(patterns): Deprecate sloppy interface guard option #2955

Merged

	redactedArgs = syncArgs.slice(0, Math.min(syncArgs.length, declaredLen));
	redactedArgs = syncArgs.slice(0, declaredLen);

	rawRestArgGuard = undefined;
	rawRestArgGuard = REDACTED_RAW_ARG;

	rawRestArgGuard = undefined;
	matchableRestArgGuard = M.any();

	const redactConfig = redactRawArgs(methodGuardPayload);
	const redactionConfig = toRedactionConfig(methodGuardPayload);

	* In return position, return the result without any hardening or ßchecking.
	* In return position, return the result without any hardening or checking.

	const context = { state, facets: null };
	const context = { state, facets: {} };

	* @typedef {'never' \| 'passable' \| 'raw'} DefaultGuardType
	* @typedef {undefined \| 'passable' \| 'raw'} DefaultGuardType

	* @typedef {{}} RawGuardPayload
	* @typedef {object} RawGuardPayload

	* options: {defaultGuards?: 'passable' \| 'raw', sloppy?: true }) => InterfaceGuard<any>
	* options: {defaultGuards?: DefaultGuardType, sloppy?: true }) => InterfaceGuard<any>

Conversation

michaelfig commented Oct 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

Uh oh!

erights left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

michaelfig commented Oct 27, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gibson042 left a comment

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!

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!

michaelfig commented Oct 27, 2023 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

erights left a comment

Choose a reason for hiding this comment

Uh oh!

gibson042 commented Oct 28, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michaelfig commented Oct 12, 2023 •

edited

Loading

michaelfig commented Oct 27, 2023 •

edited

Loading

gibson042 Oct 28, 2023 •

edited

Loading

gibson042 Oct 28, 2023 •

edited

Loading

gibson042 Oct 28, 2023 •

edited

Loading