[{"author": "Mike English", "text": "

Hello from Sparta, MI, USA

", "time": "2023-11-06T12:02:42Z"}, {"author": "Murray Kucherawy", "text": "

This! Is! Sparta!

", "time": "2023-11-06T12:02:57Z"}, {"author": "Christian Huitema", "text": "

Hello from Friday Harbor, WA, USA.

", "time": "2023-11-06T12:07:02Z"}, {"author": "Christian Huitema", "text": "

The night is very dark here...

", "time": "2023-11-06T12:07:22Z"}, {"author": "Christian Huitema", "text": "

How, and clicking the Zulip tab in the agenda gets you to the chat of the last meeting, in July! Look for \"ietf 118\" on the left hand column

", "time": "2023-11-06T12:08:02Z"}, {"author": "Christian Huitema", "text": "

Are you showing slides in the room?

", "time": "2023-11-06T12:09:57Z"}, {"author": "Daniel Havey", "text": "

Are the slides being shown remotely?

", "time": "2023-11-06T12:10:02Z"}, {"author": "Francesco Chemolli", "text": "

For the sound engineers, would it be possible to raise the volume on the streamed content? It's pretty low. Thanks!

", "time": "2023-11-06T12:10:08Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

There were no slides for this bit.

", "time": "2023-11-06T12:10:16Z"}, {"author": "Suhas Nandakumar", "text": "

no slides yet

", "time": "2023-11-06T12:10:33Z"}, {"author": "Madhan Kanagarathinam", "text": "

It is fine now !!

", "time": "2023-11-06T12:10:34Z"}, {"author": "altanai", "text": "

this is better thanks

", "time": "2023-11-06T12:10:41Z"}, {"author": "Roni Even", "text": "

I switched to older version and the audio is ok. The new version low audio

", "time": "2023-11-06T12:11:14Z"}, {"author": "Suhas Nandakumar", "text": "

newer the calmer :-)

", "time": "2023-11-06T12:11:33Z"}, {"author": "Lorenzo Miniero", "text": "

Roni: the audio is the same in old and new version, we just raised the volume from here, so that's why you hear it louder

", "time": "2023-11-06T12:12:11Z"}, {"author": "Jonathan Lennox", "text": "

Meetecho and/or AV: audio from the floor mic is quite loud on the room speakers.

", "time": "2023-11-06T12:20:57Z"}, {"author": "Lorenzo Miniero", "text": "

Notifying the AV team

", "time": "2023-11-06T12:21:29Z"}, {"author": "Harald Alvestrand", "text": "

What may be obvious to many: Is explicit signaling an optional feature, or something everyone will have to use all the time if defined?

", "time": "2023-11-06T12:30:50Z"}, {"author": "Victor Vasiliev", "text": "

I think that as we dive more in-depth into how we deal with congestion and priorities, we will inevitably have to tweak the mapping, so I am personally fine with any minimalistic explicit signal

", "time": "2023-11-06T12:31:44Z"}, {"author": "Suhas Nandakumar", "text": "

+1 to Victor ..

", "time": "2023-11-06T12:34:13Z"}, {"author": "Ted Hardie", "text": "

I'm not entering the queue, because I bet Will will make my point--VoD may deliver the bits months later, so there isn't even any way to error to the publisher and have them change it.

", "time": "2023-11-06T12:34:25Z"}, {"author": "Will Law", "text": "

+1 ted

", "time": "2023-11-06T12:36:09Z"}, {"author": "Luke Curley", "text": "

changing the mode/protocol after some time makes sense

", "time": "2023-11-06T12:37:24Z"}, {"author": "Luke Curley", "text": "

but I don't want every application and every decoder required to support every permutation of stream/object mapping

", "time": "2023-11-06T12:37:45Z"}, {"author": "Luke Curley", "text": "

because the relay decided it wanted to remap things on a whim

", "time": "2023-11-06T12:38:03Z"}, {"author": "Victor Vasiliev", "text": "

I think it's fine for relay to bundle things in some cases (the most extreme being MoQ over WebTransport-HTTP/2), but I agree with Luke that relays splitting things is bad

", "time": "2023-11-06T12:38:12Z"}, {"author": "Glenn Goldstein", "text": "

smart endpoints and dumb pipes, please.

", "time": "2023-11-06T12:40:01Z"}, {"author": "Ted Hardie", "text": "

For what it's worth, I don't think we're talking about the relay doing something arbitrary. It's the party mediating between the preferences of the publisher and the constraints expressed by the recipient. If you choose to deny it the ability to mediate and force it to stop deliverying months later from a cache, you're making a system that will break faster and more often than it needs to.

", "time": "2023-11-06T12:42:04Z"}, {"author": "Alex Chernyakhovsky", "text": "

Isn't half the point of moq to build a slightly smarter pipe...?

", "time": "2023-11-06T12:42:45Z"}, {"author": "Ted Hardie", "text": "

The publisher obviously won't ever be able to tell if it did something different in the end; it's an uncheckable MUST.

", "time": "2023-11-06T12:42:52Z"}, {"author": "Luke Curley", "text": "

@alex yeah, that's why it's very important to control how media is broken into streams and prioritized/dropped

", "time": "2023-11-06T12:44:05Z"}, {"author": "Luke Curley", "text": "

but I want the smarts on the ends of the pipe

", "time": "2023-11-06T12:45:05Z"}, {"author": "Alex Chernyakhovsky", "text": "

\"smarts on the ends of the pipe\" meaning the publisher and client? Or as explicit notifications for relays to do smart things?

", "time": "2023-11-06T12:47:27Z"}, {"author": "Will Law", "text": "

The pipes, once built, will be difficult, slow and expensive to change. So the flexibility (intelligence) should reside in the publisher and subscribers, where its much easier to change.

", "time": "2023-11-06T12:47:43Z"}, {"author": "Ali Begen", "text": "

For me, explicit notifications for relays to do the right/smart thing

", "time": "2023-11-06T12:48:04Z"}, {"author": "Mike English", "text": "

@Mo I think this is where I think we may have a deficiency in available terminology. I want to treat \"group\" as \"stream\" (plus some hand waving about what to do with reconnects, etc.) so you'd service those other use cases by just changing how you put things into \"groups\"

", "time": "2023-11-06T12:48:08Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Will Law it is not obvious to me why the relays will be harder to change than the publisher/subscriber endpoints

", "time": "2023-11-06T12:48:33Z"}, {"author": "Mike English", "text": "

But the way we currently define groups is oriented in terms of media properties rather than transport properties

", "time": "2023-11-06T12:48:44Z"}, {"author": "Mike English", "text": "

And I think we should flip that around to get better layer

", "time": "2023-11-06T12:48:53Z"}, {"author": "Mike English", "text": "

*layering

", "time": "2023-11-06T12:48:56Z"}, {"author": "Jonathan Lennox", "text": "

I think the theory is that the publisher and subscriber are likely to be under the control of the same entity (the streaming service, e.g.) whereas the relays will be under the control of a separate entity (the CDN they contract with).

", "time": "2023-11-06T12:49:35Z"}, {"author": "Suhas Nandakumar", "text": "

Object model is tuned to an applocation and not transport

", "time": "2023-11-06T12:49:56Z"}, {"author": "Suhas Nandakumar", "text": "

@mike

", "time": "2023-11-06T12:49:59Z"}, {"author": "Jonathan Lennox", "text": "

Where the subscriber is the JS they publish

", "time": "2023-11-06T12:50:05Z"}, {"author": "Alex Chernyakhovsky", "text": "

Subscriber could be a browser, or an ancient (future) SmartTV...so it's not obvious that the Publisher can influence the Subscriber as easily here.

", "time": "2023-11-06T12:50:28Z"}, {"author": "Cullen Jennings", "text": "

+1 luke

", "time": "2023-11-06T12:50:45Z"}, {"author": "Mike English", "text": "

@suhas yes, and maybe the streaming format is what should be application oriented instead of MoQT

", "time": "2023-11-06T12:50:46Z"}, {"author": "Christian Huitema", "text": "

You may be able to \"peek\" out of order, but sending streams out of order is significantly more complex!

", "time": "2023-11-06T12:50:52Z"}, {"author": "Will Law", "text": "

@Alex - because relays will be implemented by multiple different CDNs. Coordinating a global update across .disparate entities is difficult. In comparison, I can put some special change in my publisher, matching code in my client and test something new every 5 minutes.

", "time": "2023-11-06T12:51:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

If you control the subscriber, sure. But my point was I think there will be practical deployments where that is not the case.

", "time": "2023-11-06T12:51:59Z"}, {"author": "Mike English", "text": "

Ted: I like your phrasing, and Will's clarification is kind of making my point. :P

", "time": "2023-11-06T12:52:51Z"}, {"author": "Christian Huitema", "text": "

How do I see the proposed phrasing?

", "time": "2023-11-06T12:53:24Z"}, {"author": "Mike English", "text": "

Luke: I may have been proposing that, at least as a straw man

", "time": "2023-11-06T12:53:54Z"}, {"author": "James Gruessing", "text": "

[humming intensifies]

", "time": "2023-11-06T12:54:20Z"}, {"author": "Luke Curley", "text": "

heh yeah, I don't think the MoqTransport object model is correct if you have to change its properties

", "time": "2023-11-06T12:54:26Z"}, {"author": "Mike English", "text": "

^

", "time": "2023-11-06T12:54:48Z"}, {"author": "Jonathan Lennox", "text": "

I think for this explicit signal to make sense there will need to be some new entity in the object model, that this explicit signal is mapping objects to.

", "time": "2023-11-06T12:55:39Z"}, {"author": "Luke Curley", "text": "

and yeah, fix the object model so the properties are useful, rather than add flags to change those properties

", "time": "2023-11-06T12:55:41Z"}, {"author": "Jonathan Lennox", "text": "

At least as an abstraction of the transport

", "time": "2023-11-06T12:56:40Z"}, {"author": "Peter Thatcher", "text": "

Regarding the idea that you can read QUIC streams out of order: will relays forward QUIC streams out of order? And if so, is that required or optional behavior?

", "time": "2023-11-06T12:57:30Z"}, {"author": "Alex Chernyakhovsky", "text": "

What does it mean to read streams out of order? Streams are an in-order thing in QUIC, but the streams of a connection are independent.

", "time": "2023-11-06T12:58:14Z"}, {"author": "Luke Curley", "text": "

@peter optional, but relays should do it when latency is important

", "time": "2023-11-06T12:58:18Z"}, {"author": "Victor Vasiliev", "text": "

I believe we say you should forward objects asap

", "time": "2023-11-06T12:58:32Z"}, {"author": "Victor Vasiliev", "text": "

(including objects that are not fully received)

", "time": "2023-11-06T12:58:43Z"}, {"author": "Luke Curley", "text": "

here's the discussion on out-of-order QUIC streams: https://github.com/moq-wg/moq-transport/issues/38

", "time": "2023-11-06T12:58:52Z"}, {"author": "Lucas Pardue", "text": "

https://datatracker.ietf.org/doc/html/rfc9000#section-2.2 is most relevant hree

", "time": "2023-11-06T12:59:36Z"}, {"author": "Luke Curley", "text": "

@Alex QUIC streams under the hood are offset+size frames, so in theory they can be sent/received out of order

", "time": "2023-11-06T13:00:02Z"}, {"author": "Luke Curley", "text": "

sending them out of order can be a pain due to flow control though

", "time": "2023-11-06T13:00:26Z"}, {"author": "Alex Chernyakhovsky", "text": "

Ah, sure, but I think no implementation today lets you do that (without getting sad)

", "time": "2023-11-06T13:00:28Z"}, {"author": "Luke Curley", "text": "

Quinn lets you read them out of order, but yeah not send them (yet)

", "time": "2023-11-06T13:00:46Z"}, {"author": "Alex Chernyakhovsky", "text": "

From my experience when we were working on the predecessor to CONNECT-IP before DATAGRAM existed we did horrible things to streams and it made flow control very, very sad

", "time": "2023-11-06T13:01:03Z"}, {"author": "Alex Chernyakhovsky", "text": "

So I'd suggest not summoning those demons if you can avoid it and just use DATAGRAM when you need out of order stuff.

", "time": "2023-11-06T13:01:22Z"}, {"author": "Peter Thatcher", "text": "

If it's optional, you can't rely on it. I think we should either require relays to forward QUIC streams out of order or not rely on the fact that one can read QUIC streams out of order.

", "time": "2023-11-06T13:02:05Z"}, {"author": "Alex Chernyakhovsky", "text": "

Reading out-of-order (peeking) seems like a justifiable feature

", "time": "2023-11-06T13:02:16Z"}, {"author": "Christian Huitema", "text": "

Alex, the issue with datagrams is that if the object is larger than 1K, you need several datagrams, and complexity grows quickly.

", "time": "2023-11-06T13:02:26Z"}, {"author": "Luke Curley", "text": "

note that the encoder/decoder still uses ordered streams

", "time": "2023-11-06T13:02:34Z"}, {"author": "Luke Curley", "text": "

this is just an optional feature that relays could do to minimize latency

", "time": "2023-11-06T13:02:45Z"}, {"author": "Jonathan Lennox", "text": "

I think for a relay being able to not have to buffer data following a packet loss is a good thing, though to be sure getting the flow control right is very hard.

", "time": "2023-11-06T13:03:01Z"}, {"author": "Alex Chernyakhovsky", "text": "

There's no avoiding buffering up to the size of the cwnd, is there?

", "time": "2023-11-06T13:03:29Z"}, {"author": "Alex Chernyakhovsky", "text": "

You might just be able to remove additional buffering?

", "time": "2023-11-06T13:03:42Z"}, {"author": "Jonathan Lennox", "text": "

I'm not sure, I don't have a good enough intuition about how cwnd's work. I just feel like if you have packets A, B, C, on a stream, and B is lost between the publisher and the relay, it's nice if the relay can nonetheless forward C immediately when it gets it

", "time": "2023-11-06T13:05:02Z"}, {"author": "Luke Curley", "text": "

to be clear, this is also an issue that impacts HTTP; it's just that real-time latency isn't important

", "time": "2023-11-06T13:05:03Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, this would be nice for HTTP proxies as well

", "time": "2023-11-06T13:05:26Z"}, {"author": "Simon Friedberger", "text": "

Should there be a restriction on size?

", "time": "2023-11-06T13:06:18Z"}, {"author": "Lucas Pardue", "text": "

a relay isn't forwarding packets though right?

", "time": "2023-11-06T13:06:46Z"}, {"author": "Victor Vasiliev", "text": "

The application itself may impose requirements like \"UTF-8 with Normalization Form C\", but the transport should forward as-is, would be my position

", "time": "2023-11-06T13:08:07Z"}, {"author": "Cullen Jennings", "text": "

+1 Victor

", "time": "2023-11-06T13:08:28Z"}, {"author": "Will Law", "text": "

+1 to Cullen. No restrictions at MOQT level. Streaming Formats should specify more restrictions, of which using URI friendly seems sensible.

", "time": "2023-11-06T13:08:44Z"}, {"author": "Jonathan Lennox", "text": "

Victor: and more to the point the form in client subscription requests must be bitwise-identical to the version from the publisher

", "time": "2023-11-06T13:08:55Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Jonathan Lennox sure, but the relay cannot avoid holding onto C until after the cwnd advanced past it. So you can certainly (flow control permitting) send C early [since the relax is basically a router at this point, not a proxy], but honestly I am not sure I would even consider this \"writing out of order\" in that view

", "time": "2023-11-06T13:09:25Z"}, {"author": "Lucas Pardue", "text": "

what about language tags?

", "time": "2023-11-06T13:09:30Z"}, {"author": "Victor Vasiliev", "text": "

if you mix NFC and NFD, and your track isn't found, you get to keep the pieces

", "time": "2023-11-06T13:09:31Z"}, {"author": "Cullen Jennings", "text": "

Luke, I think you are arguing Option 3 at the catalog level

", "time": "2023-11-06T13:09:36Z"}, {"author": "Jonathan Lennox", "text": "

Alex: Yeah, I didn't really mean \"not buffering\", so much as avoiding introducing additional HOLB and wasting available bandwidth while B is retransmitted. Agreed the relay still has to be prepared for C to be lost on its downlink.

", "time": "2023-11-06T13:10:38Z"}, {"author": "Lucas Pardue", "text": "

QUIC had this problem when we declared the CONNECTION_CLOSE reason phrase as \"human-readable\". We worked around it by stating:

\n

Reason Phrase:
\nAdditional diagnostic information for the closure. This can be zero length if the sender chooses not to give details beyond the Error Code value. This SHOULD be a UTF-8 encoded string [RFC3629], though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text.

\n

not sure that works here.

", "time": "2023-11-06T13:11:04Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Jonathan Lennox +1 that makes sense to me.

", "time": "2023-11-06T13:11:47Z"}, {"author": "Mike English", "text": "

Reflecting back on the object/group -> stream/datagram mapping discussion, I can see the need now to preserve the current object and group definitions, but we need to stop trying to overload them, which means we need to augment them with new terms. This lands me firmly in the explicit signaling (something we need is currently missing) camp.

", "time": "2023-11-06T13:13:35Z"}, {"author": "Luke Curley", "text": "

@cullen selfishly, it's just a lot easier to use utf-8 strings in a MoQ library for logging

", "time": "2023-11-06T13:13:48Z"}, {"author": "Harald Alvestrand", "text": "

So this is a case not of what the protocol does, but \"in what other contexts does this sequence of bytes pop up?\"

", "time": "2023-11-06T13:14:19Z"}, {"author": "Victor Vasiliev", "text": "

I'm sure there's a way to escape those when logging

", "time": "2023-11-06T13:14:27Z"}, {"author": "Mike English", "text": "

+1 Christian. Even if we're talking about raw byte comparisons for equality there still end up being potential finicky issues like endianness that can be problematic

", "time": "2023-11-06T13:14:27Z"}, {"author": "Harald Alvestrand", "text": "

There are a thousand ways to escape those when logging, and that's part of the problem.

", "time": "2023-11-06T13:14:50Z"}, {"author": "Victor Vasiliev", "text": "

I'm not sure endianness is a problem for bytestring equality

", "time": "2023-11-06T13:15:58Z"}, {"author": "Luke Curley", "text": "

@victor if the name is Vec<byte>, then for logging I basically have to hex encode everything

", "time": "2023-11-06T13:16:50Z"}, {"author": "Harald Alvestrand", "text": "

for instance, when you do UTF-8 with U+ escaping for invalid byte sequences, you get all the string equivalence issues - the log seems to show the same name for two different streams.

", "time": "2023-11-06T13:16:51Z"}, {"author": "Luke Curley", "text": "

even though the actual name is supposed to be human readable

", "time": "2023-11-06T13:17:14Z"}, {"author": "Luke Curley", "text": "

but yeah if there's pitfalls in UTF-8 equality then we should not use it

", "time": "2023-11-06T13:17:35Z"}, {"author": "Lucas Pardue", "text": "

human-readable has a very specific meaning in the IETF, be carefule what you wish for

", "time": "2023-11-06T13:17:39Z"}, {"author": "Peter Thatcher", "text": "

+1 to Cullen about namespaces and authorization

", "time": "2023-11-06T13:17:41Z"}, {"author": "Victor Vasiliev", "text": "

I will just log EscapeCString(track_name), which mostly works

", "time": "2023-11-06T13:17:53Z"}, {"author": "Harald Alvestrand", "text": "

Having this restriction as \"the namespace manager needs to have a stated rule and enforce it\" might be a reasonable layering.

", "time": "2023-11-06T13:18:17Z"}, {"author": "Harald Alvestrand", "text": "

Just hope the people who write the eventual Javascript API to this choose to give names in UTF-8 not UTF-16....

", "time": "2023-11-06T13:19:12Z"}, {"author": "Luke Curley", "text": "

@harvald https://github.com/kixelated/moq-js

", "time": "2023-11-06T13:20:28Z"}, {"author": "Luke Curley", "text": "
id: bigint\nnamespace: string\nname: string\n
", "time": "2023-11-06T13:20:57Z"}, {"author": "Luke Curley", "text": "

oh nooo

", "time": "2023-11-06T13:21:02Z"}, {"author": "Christian Huitema", "text": "

If you don't dedup, does the client checks that all copies of object 17 are the same?

", "time": "2023-11-06T13:22:11Z"}, {"author": "Kirill Pugin", "text": "

how is this different from HTTP GET?

", "time": "2023-11-06T13:23:53Z"}, {"author": "Mike English", "text": "

^

", "time": "2023-11-06T13:24:13Z"}, {"author": "Victor Vasiliev", "text": "

I seem to recall that HTTP GET has a lot of notorious pathological behavior cases with requesting overlapping ranges

", "time": "2023-11-06T13:25:04Z"}, {"author": "Lucas Pardue", "text": "

if the client asks for dupes, it can implement it's own FEC :D

", "time": "2023-11-06T13:25:11Z"}, {"author": "Victor Vasiliev", "text": "

See https://httpd.apache.org/security/CVE-2011-3192.txt for instance

", "time": "2023-11-06T13:25:31Z"}, {"author": "Mike English", "text": "

The most common use case for multiple subscribes that comes to mind for me is using subscribe hints to make GET-like requests for specific objects

", "time": "2023-11-06T13:25:38Z"}, {"author": "Jonathan Rosenberg", "text": "

The main use case I had in mind for multiple subscribes is make-before-break handoff of a conference from one relay to another. For that use case you want to receive duplicates during the transition

", "time": "2023-11-06T13:28:10Z"}, {"author": "Ted Hardie", "text": "

@Jonathan do you want that reflected to the room?

", "time": "2023-11-06T13:28:44Z"}, {"author": "Kirill Pugin", "text": "

@Luke to me this is application level problem

", "time": "2023-11-06T13:29:55Z"}, {"author": "Lucas Pardue", "text": "

thundering herd!

", "time": "2023-11-06T13:31:29Z"}, {"author": "Luke Curley", "text": "

yeah exactly, gotta dedup the thundering herd

", "time": "2023-11-06T13:32:54Z"}, {"author": "Luke Curley", "text": "

shield mah origin

", "time": "2023-11-06T13:33:02Z"}, {"author": "Kirill Pugin", "text": "

sure, but why does it need to be prescribed?

", "time": "2023-11-06T13:33:24Z"}, {"author": "Lucas Pardue", "text": "

+1 kirill. this seems pretty similar to challenges that are already faced by e.g. HTTP intermediation and that it is an implementation choice driven by the market. Rather than something that has to be mandated

", "time": "2023-11-06T13:34:09Z"}, {"author": "Luke Curley", "text": "

well there needs to be a mechanism to deduplicate

", "time": "2023-11-06T13:34:47Z"}, {"author": "Peter Thatcher", "text": "

+1 to Will Law and subscription aggregation from relay

", "time": "2023-11-06T13:35:21Z"}, {"author": "Luke Curley", "text": "

like the relay needs to be able to ask the mobile phone to only send an OBJECT once matching rules XYZ that may change dynamically

", "time": "2023-11-06T13:35:35Z"}, {"author": "Alan Frindell", "text": "

I think the auth case may require many subscriptions forwarded from the relay but you would want them to be deduped

", "time": "2023-11-06T13:35:46Z"}, {"author": "Ted Hardie", "text": "

Cullen, we cut the queue.

", "time": "2023-11-06T13:36:03Z"}, {"author": "Lucas Pardue", "text": "

sure - spec the way to do it and the considerations, but don't mandate exactly what to do in what circumstances

", "time": "2023-11-06T13:36:05Z"}, {"author": "Luke Curley", "text": "

oh yeah, we shouldn't error if there are duplicates

", "time": "2023-11-06T13:37:00Z"}, {"author": "Luke Curley", "text": "

how does this approach work for identical SUBSCRIBE messages with different auth parameters?

", "time": "2023-11-06T13:38:59Z"}, {"author": "Jonathan Rosenberg", "text": "

I agree with Ted - that sequence would be required for make before you break moves

", "time": "2023-11-06T13:41:54Z"}, {"author": "Will Law", "text": "

No point in waiting.

", "time": "2023-11-06T13:47:24Z"}, {"author": "Cullen Jennings", "text": "

+1 on punt the resource limits for now

", "time": "2023-11-06T13:50:57Z"}, {"author": "Victor Vasiliev", "text": "

WebTransport in W3C API uses concurrent limit instead of concurrect because it's an API

", "time": "2023-11-06T13:52:42Z"}, {"author": "Alan Frindell", "text": "

+1 API and implementation can be different

", "time": "2023-11-06T13:53:01Z"}, {"author": "Luke Curley", "text": "

SAVING MY HAND

", "time": "2023-11-06T13:54:41Z"}, {"author": "Alan Frindell", "text": "

Is this wire with deck chairs sinking?

", "time": "2023-11-06T13:56:53Z"}]