[{"author": "Tommy Pauly", "text": "

Come for the technology, stay for the memes?

", "time": "2022-11-09T13:00:51Z"}, {"author": "Lorenzo Miniero", "text": "

FYI, when slides are missing you can follow this short tutorial to get them to appear: https://www.youtube.com/watch?v=pxxhDEsFK8Y

\n
", "time": "2022-11-09T13:01:02Z"}, {"author": "Richard Barnes", "text": "

https://notes.ietf.org/notes-ietf-115-ohai#

", "time": "2022-11-09T13:01:25Z"}, {"author": "Francesca Palombini", "text": "

hello! just connected and I am impressed we are already this far in the presentation :D

", "time": "2022-11-09T13:06:06Z"}, {"author": "Richard Barnes", "text": "

we run a very efficient wg, @Francesca

", "time": "2022-11-09T13:06:21Z"}, {"author": "Richard Barnes", "text": "

'ohttp' seems fine to me

", "time": "2022-11-09T13:08:23Z"}, {"author": "David Schinazi", "text": "

OHTTPSGTM

", "time": "2022-11-09T13:08:27Z"}, {"author": "Mark Nottingham", "text": "

I'm not horribly against ohttp

", "time": "2022-11-09T13:08:36Z"}, {"author": "Francesca Palombini", "text": "

By the way - apologies to the wg and authors for the delay in processing the ohttp doc, it is now 1st on my priority list of docs

", "time": "2022-11-09T13:09:08Z"}, {"author": "Martin Thomson", "text": "

Ben's point about the need for broader understanding is interesting

", "time": "2022-11-09T13:09:37Z"}, {"author": "Richard Barnes", "text": "

Ben's point about broader behavior change seems a little expansive

", "time": "2022-11-09T13:11:26Z"}, {"author": "Nick Doty", "text": "

can you use this for the simple case to just indicate, my regular old server welcomes oblivious requests?

", "time": "2022-11-09T13:11:43Z"}, {"author": "David Schinazi", "text": "

dooh dooh?

", "time": "2022-11-09T13:12:12Z"}, {"author": "Tommy Pauly", "text": "

DoOh

", "time": "2022-11-09T13:12:21Z"}, {"author": "Daniel Gillmor", "text": "

thanks david, someone had to say it

", "time": "2022-11-09T13:12:24Z"}, {"author": "Tommy Pauly", "text": "

DoOH, rather

", "time": "2022-11-09T13:12:25Z"}, {"author": "Shivan Sahib", "text": "

DoOH sounds like you're mocking the protocol

", "time": "2022-11-09T13:12:36Z"}, {"author": "Andrew Campling", "text": "

So would this replace the current, experimental ODoH doc?

", "time": "2022-11-09T13:13:14Z"}, {"author": "Richard Barnes", "text": "

run CalDAV over OHTTP, and you'll have a carboxylic acid

", "time": "2022-11-09T13:14:21Z"}, {"author": "David Schinazi", "text": "

DnS oVeR oBlIvIoUs HtTp?

", "time": "2022-11-09T13:14:44Z"}, {"author": "Richard Barnes", "text": "

lots of DNS here. would be good not to over-index on that case

", "time": "2022-11-09T13:17:52Z"}, {"author": "Benjamin Schwartz", "text": "

My complaint earlier is about paragraph 3 of https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp-05#section-4.6, which discusses the other design. I guess it's fine, but maybe a sentence like \"Note that this is not the arrangement specified in [...].\"

", "time": "2022-11-09T13:18:13Z"}, {"author": "Ted Hardie", "text": "

Does that create a forward reference that would cause the doc to get stuck in the RFC Editor queue?

", "time": "2022-11-09T13:18:54Z"}, {"author": "Richard Barnes", "text": "

+1 this seems like a DDR problem

", "time": "2022-11-09T13:19:22Z"}, {"author": "Benjamin Schwartz", "text": "

Informative reference, so ... maybe not?

", "time": "2022-11-09T13:19:22Z"}, {"author": "Andrew Campling", "text": "

@Richard To coordinate the various DNS aspects with the DNS directorate?

", "time": "2022-11-09T13:19:31Z"}, {"author": "Richard Barnes", "text": "

@Andrew i just mean the solution here should be HTTP-generic, not DoH-specific

", "time": "2022-11-09T13:19:49Z"}, {"author": "Richard Barnes", "text": "

(or DoOH)

", "time": "2022-11-09T13:19:58Z"}, {"author": "Ted Hardie", "text": "

If it's informative, then the later one kind of doesn't over-ride the example. I agree that's better than blank, but removing the example seems cleaner to me personally.

", "time": "2022-11-09T13:20:18Z"}, {"author": "Richard Barnes", "text": "

DoOQ?

", "time": "2022-11-09T13:21:05Z"}, {"author": "David Schinazi", "text": "

or ODoQ?

", "time": "2022-11-09T13:21:15Z"}, {"author": "Shivan Sahib", "text": "

makes sense

", "time": "2022-11-09T13:23:21Z"}, {"author": "Erik Nygren", "text": "

+1 to Tommy as otherwise introducing future protocols would be a mess

", "time": "2022-11-09T13:23:32Z"}, {"author": "Andrew Campling", "text": "

Don't forget ODoHoT (Oblivious DoH over Tor)

", "time": "2022-11-09T13:24:05Z"}, {"author": "Richard Barnes", "text": "

strong consensus!

", "time": "2022-11-09T13:24:56Z"}, {"author": "Shivan Sahib", "text": "

making me nervous

", "time": "2022-11-09T13:25:11Z"}, {"author": "Richard Barnes", "text": "

everyone agrees, can't possibly go wrong with that

", "time": "2022-11-09T13:25:30Z"}, {"author": "Daniel Gillmor", "text": "

sad consensus though, because the end user does want \"obliviousness\" across all layers at the same time.

", "time": "2022-11-09T13:25:32Z"}, {"author": "Erik Nygren", "text": "

ODoHoToDoH (Oblivious DNS over HTTP over TCP over DNS over HTTP, which I'm sure someone will implement at some point)

", "time": "2022-11-09T13:25:57Z"}, {"author": "Daniel Gillmor", "text": "

:shocked_face_with_exploding_head:

", "time": "2022-11-09T13:26:14Z"}, {"author": "Ted Hardie", "text": "

Can the gain on Tiru's mic go up a bit? He's a bit hard to hear from the back.

", "time": "2022-11-09T13:28:00Z"}, {"author": "Benjamin Schwartz", "text": "

Sounds good remotely FYI

", "time": "2022-11-09T13:28:18Z"}, {"author": "Daniel Gillmor", "text": "

i like that \"legitimate requests\" is in appropriate scare quotes

", "time": "2022-11-09T13:29:44Z"}, {"author": "Nick Doty", "text": "

if the target knows which requests are malicious, can't it just drop those requests, rather than asking the relay to rate limit them?

", "time": "2022-11-09T13:30:50Z"}, {"author": "Richard Barnes", "text": "

@Nick the idea is to have the relay quench the request so they don't even reach the target

", "time": "2022-11-09T13:31:25Z"}, {"author": "Andrew Campling", "text": "

Dropping malicious requests seems like a good idea

", "time": "2022-11-09T13:31:35Z"}, {"author": "Andrew Campling", "text": "

(Or quenching them)

", "time": "2022-11-09T13:31:54Z"}, {"author": "Eric Orth", "text": "

What about cases where the server suspects, but doesn't know, requests are from the same user? Wouldn't this mechanism allow confirming the unmasking to the server?

", "time": "2022-11-09T13:34:06Z"}, {"author": "Jonathan Hoyland", "text": "

@Daniel Gillmor Can you increase your mic gain please? It's hard to hear at the back

", "time": "2022-11-09T13:34:10Z"}, {"author": "Mohamed Boucadair", "text": "

@Nick: In case of DDoS, rate-limiting at the target may be suboptimal compared to softening this at the relay level, which would avoid overloading the target

", "time": "2022-11-09T13:34:50Z"}, {"author": "Daniel Gillmor", "text": "

Jonathan, sorry about that. I was just saying that this doesn't seem to match the expectations i'd have for obliviousness/non-linkability as an OHAI client

", "time": "2022-11-09T13:35:05Z"}, {"author": "Daniel Gillmor", "text": "

this proposal is also explicitly asking relays to keep more elaborate state about each of its clients

", "time": "2022-11-09T13:35:53Z"}, {"author": "Tommy Pauly", "text": "

Agreed with DKG

", "time": "2022-11-09T13:36:10Z"}, {"author": "Nick Doty", "text": "

@Mohamed, perhaps, but ohttp relays are probably not the best way to enable DDoS protections. you could have a DDoS service between the oblivious relay and the target

", "time": "2022-11-09T13:36:49Z"}, {"author": "Andrew Campling", "text": "

Perhaps some sort of middlebox? :-)

", "time": "2022-11-09T13:37:31Z"}, {"author": "Jonathan Hoyland", "text": "

@Nick Doty the issue is that DDoS is much less effective if you can't inspect the packet contents.

", "time": "2022-11-09T13:37:40Z"}, {"author": "Daniel Gillmor", "text": "

DDoS is less effective? or anti-DDoS is less effective?

", "time": "2022-11-09T13:38:01Z"}, {"author": "Jonathan Hoyland", "text": "

Sorry, you're right DDoS protection is less effective

", "time": "2022-11-09T13:38:24Z"}, {"author": "Daniel Gillmor", "text": "

gotcha, thanks. thinking like an attacker vs. thinking like an attacker's attacker\u2026 it's attackers all the way down.

", "time": "2022-11-09T13:39:09Z"}, {"author": "Shivan Sahib", "text": "

is anyone else's internet in the room cutting out

", "time": "2022-11-09T13:39:09Z"}, {"author": "Jonathan Hoyland", "text": "

The higher you go up the stack the more accurately you can detect DDoS traffic, and the more options you have to mitigate.

", "time": "2022-11-09T13:39:11Z"}, {"author": "Benjamin Schwartz", "text": "

It is common for DDoS requests to have a common pattern, and for people to write a regex to match against them and drop them as early as possible and adds the source IPs to a blocklist. OHTTP makes that last part ~impossible.

", "time": "2022-11-09T13:39:28Z"}, {"author": "Nick Doty", "text": "

I think the utility is that these \"2\" requests are _sus_, not clearly malicious, and only the relay will know if it's the same user sending many sus requests, rather than it happening every now and again

", "time": "2022-11-09T13:39:35Z"}, {"author": "Jonathan Hoyland", "text": "

Exactly, and you can't exactly captcha here

", "time": "2022-11-09T13:40:02Z"}, {"author": "Jonathan Hoyland", "text": "

Unless you want to start talking PrivacyPass

", "time": "2022-11-09T13:40:19Z"}, {"author": "Daniel Gillmor", "text": "

Nick, why is that useful to the relay? because they're trying to track their users? that's the thing i don't want my relay to be doing, no?

", "time": "2022-11-09T13:40:19Z"}, {"author": "Nick Doty", "text": "

if you can tell that a request is malicious, you should instead have a reverse proxy or something internal that drops the malicious requests before they get to the expensive calculation

", "time": "2022-11-09T13:40:47Z"}, {"author": "Jonathan Hoyland", "text": "

Also the relay would need some logic to deal with CGNAT

", "time": "2022-11-09T13:40:59Z"}, {"author": "Nick Doty", "text": "

@dkg I think it's supposed to be useful to the relay because the relay doesn't want all its clients to get throttled

", "time": "2022-11-09T13:41:45Z"}, {"author": "Benjamin Schwartz", "text": "

I think probably we will see gateways ratelimiting relays that send abusive traffic, and relays will then try to apply some kind of ratelimiting that limits attacks more than it harms legitimate users. That might just be fair queueing, but even fair queueing requires maintaining per-client state and creates a potential timing leak.

", "time": "2022-11-09T13:42:03Z"}, {"author": "Benjamin Schwartz", "text": "

Maybe it's fine, but somebody smart should think about it.

", "time": "2022-11-09T13:42:31Z"}, {"author": "Nick Doty", "text": "

@dkg I think the client isn't depending on the relay not counting its traffic, you just rely on the relay not sharing identifiers with the target

", "time": "2022-11-09T13:42:33Z"}, {"author": "Mohamed Boucadair", "text": "

@daniel: if the relay does not collaborate, \"legitimate\" requests will be discarded by the target because they are sharing the same IP address as a misbehaving user served by the same relay

", "time": "2022-11-09T13:42:51Z"}, {"author": "Jonathan Hoyland", "text": "

+1 on the potential timing leak

", "time": "2022-11-09T13:43:06Z"}, {"author": "Nikita Borisov", "text": "

fundamentally it feels like in this scenario the target is asking the relays to link client requests, whereas the clients are asking the relay NOT to link them, and whom is the relay going to trust?

", "time": "2022-11-09T13:43:12Z"}, {"author": "Daniel Gillmor", "text": "

+1 Nikita; that's an insightful summary

", "time": "2022-11-09T13:43:37Z"}, {"author": "Mohamed Boucadair", "text": "

There are tard-offs, but the key properties is to unmask the client as a result of processing the request from the target.

", "time": "2022-11-09T13:45:12Z"}, {"author": "Jonathan Hoyland", "text": "

With the unreliable delivery draft, can the relay inject fake accepts?

", "time": "2022-11-09T13:45:40Z"}, {"author": "Andrew Campling", "text": "

@Nikita potentially the non-malicious clients want anonymity but also want some sort of intervention / action so that they do not suffer from rate limiting

", "time": "2022-11-09T13:46:20Z"}, {"author": "Benjamin Schwartz", "text": "

+1 Adopt unreliable.

", "time": "2022-11-09T13:46:22Z"}, {"author": "Richard Barnes", "text": "

@Ben maybe go to the mic with why you like it?

", "time": "2022-11-09T13:46:54Z"}, {"author": "Martin Thomson", "text": "

OSS - oblivious submission service ?

", "time": "2022-11-09T13:48:34Z"}, {"author": "David Schinazi", "text": "

We've really run out of TLAs

", "time": "2022-11-09T13:49:17Z"}, {"author": "Martin Thomson", "text": "

there's some value in reusing the machinery of OHTTP for building that service

", "time": "2022-11-09T13:49:24Z"}, {"author": "Martin Thomson", "text": "

but I want to ensure that Ted's concerns are handled appropriately

", "time": "2022-11-09T13:49:50Z"}, {"author": "Jonathan Hoyland", "text": "

Building UDP over OHTTP -> UoO

", "time": "2022-11-09T13:50:09Z"}, {"author": "Martin Thomson", "text": "

To be clear, what you are really looking for here, is an encapsulation of a single message

", "time": "2022-11-09T13:50:43Z"}, {"author": "Shivan Sahib", "text": "

Async OHTTP?

", "time": "2022-11-09T13:50:56Z"}, {"author": "David Schinazi", "text": "

OWOHTTP?

", "time": "2022-11-09T13:51:02Z"}, {"author": "Martin Thomson", "text": "

This is no longer OHTTP

", "time": "2022-11-09T13:51:03Z"}, {"author": "Jonathan Hoyland", "text": "

Async implies await, no?

", "time": "2022-11-09T13:51:16Z"}, {"author": "Richard Barnes", "text": "

i don't understand how this saves configuring a key? like you still need HPKE to decrypt the request

", "time": "2022-11-09T13:52:15Z"}, {"author": "Martin Thomson", "text": "

The concern Ralph has is about whether the key is online or offline

", "time": "2022-11-09T13:52:29Z"}, {"author": "Jonathan Hoyland", "text": "

Just do HPKE over UDP?

", "time": "2022-11-09T13:52:33Z"}, {"author": "Martin Thomson", "text": "

If you never have to reply, you don't need an online key.

", "time": "2022-11-09T13:52:42Z"}, {"author": "Tommy Pauly", "text": "

I don't think UDP is really applicable here \u2014 it's no really unreliable, the name is misleading

", "time": "2022-11-09T13:52:55Z"}, {"author": "Richard Barnes", "text": "

thanks mt

", "time": "2022-11-09T13:52:55Z"}, {"author": "Jonathan Hoyland", "text": "

The client has no way to know the packet was delivered

", "time": "2022-11-09T13:53:22Z"}, {"author": "Tommy Pauly", "text": "

It mainly seems like the value is to have a one-way upload where you don't want to wait for a reponse because it could get uploaded way later

", "time": "2022-11-09T13:53:34Z"}, {"author": "Martin Thomson", "text": "

@Tommy Pauly oh, this is entirely unreliable - no response means no e2e confirmation of delivery

", "time": "2022-11-09T13:53:36Z"}, {"author": "Tommy Pauly", "text": "

Sure, no confirmation of delivery, but the point is not to imitate UDP

", "time": "2022-11-09T13:53:54Z"}, {"author": "Martin Thomson", "text": "

yes, it's not UDP

", "time": "2022-11-09T13:54:06Z"}, {"author": "Ted Hardie", "text": "

@Tommy so if this is valuable as a class of behavior, why is this not in regular proxies which are not oblivious?

", "time": "2022-11-09T13:54:32Z"}, {"author": "Richard Barnes", "text": "

Reminder: This is not the Oblivioius SMTP WG

", "time": "2022-11-09T13:55:04Z"}, {"author": "Tommy Pauly", "text": "

@Ben seems to be arguing that it could be in regular proxies. A \"I'm willing to disconnect my connection and stop waiting if you're going to delay or batch the upload\"

", "time": "2022-11-09T13:55:12Z"}, {"author": "Andrew Campling", "text": "

Unidirectional OHTTP?

", "time": "2022-11-09T13:55:12Z"}, {"author": "Tommy Pauly", "text": "

@Richard, aw man when is OSMTP meeting??

", "time": "2022-11-09T13:55:28Z"}, {"author": "Ted Hardie", "text": "

Specify batch-via-proxy in HTTPbis and then making it oblivious would be a very different route to this--do you think that would fly?

", "time": "2022-11-09T13:55:31Z"}, {"author": "Martin Thomson", "text": "

We trust the relay not to do that

", "time": "2022-11-09T13:55:48Z"}, {"author": "Nikita Borisov", "text": "

Is there a use case for non-oblivious batching?

", "time": "2022-11-09T13:56:05Z"}, {"author": "Nick Doty", "text": "

a misbehaving relay can already pass on identifying information about the client

", "time": "2022-11-09T13:56:08Z"}, {"author": "Nikita Borisov", "text": "

I think that batching is very interesting from a privacy perspective but also a very different modality than OHTTP

", "time": "2022-11-09T13:56:30Z"}, {"author": "Tommy Pauly", "text": "

Well in the normal HTTP case, if I post to a proxy, it can respond and say OK. In this case, my post to the relay can say it's OK, I just don't get the end-to-end OK from the gateway. So that doesn't apply to a normal HTTP reverse proxy.

", "time": "2022-11-09T13:57:09Z"}, {"author": "Benjamin Schwartz", "text": "

Proxy-Allow-Delay=(10 minutes)

", "time": "2022-11-09T13:57:42Z"}, {"author": "Nikita Borisov", "text": "

I think since the batching can provide a privacy benefit, the user needs to have a clear expectation of what the proxy does. There's a very big difference between \"may delay\" and \"will delay/batch\"

", "time": "2022-11-09T13:58:45Z"}, {"author": "Richard Barnes", "text": "

Proxy-Allow-Delay=\\infty

", "time": "2022-11-09T13:58:54Z"}, {"author": "Benjamin Schwartz", "text": "

@Nikita Borisov I don't think so. The client trusts the relay to take all reasonable steps to protect client privacy. For example, the client doesn't know whether the relay uses padding on the relay-gateway link.

", "time": "2022-11-09T13:59:50Z"}, {"author": "Eric Rescorla", "text": "

So I do think that the batching has a certain level of merit, but I think the answer is actually to make it more complicated, which is by finding some way to prevent the relay from blocking submissions silently

", "time": "2022-11-09T14:01:11Z"}, {"author": "Eric Rescorla", "text": "

i do not in fact have a design to hand for this.

", "time": "2022-11-09T14:01:32Z"}, {"author": "Richard Barnes", "text": "

i'm not sure why we need to push the batching down to the HTTP level, as opposed to just handling it at the application layer

", "time": "2022-11-09T14:02:02Z"}, {"author": "Eric Rescorla", "text": "

Well, I think the idea is that you want the proxy to batch

", "time": "2022-11-09T14:02:39Z"}, {"author": "Daniel Gillmor", "text": "

fastest reboot ever

", "time": "2022-11-09T14:03:10Z"}, {"author": "Nikita Borisov", "text": "

@Benjamin Schwartz I think it's important for the client to understand what privacy properties to expect from a relay, rather than \"best effort\" privacy

", "time": "2022-11-09T14:05:58Z"}, {"author": "Eric Rescorla", "text": "

This are some really terrifying caveats

", "time": "2022-11-09T14:06:21Z"}, {"author": "Nick Doty", "text": "

wait, how does signing assure consistency? can't the attacker sign multiple versions and hand them out to different users?

", "time": "2022-11-09T14:08:05Z"}, {"author": "Daniel Gillmor", "text": "

Nick, i think you're right that signing does not assure consistency

", "time": "2022-11-09T14:08:29Z"}, {"author": "Richard Barnes", "text": "

it would depend on the signer not signing duplicate things, i think

", "time": "2022-11-09T14:09:25Z"}, {"author": "David Schinazi", "text": "

Why not put the keys on the blockchain?

", "time": "2022-11-09T14:09:43Z"}, {"author": "Richard Barnes", "text": "

CT would sort in fact of solve this

", "time": "2022-11-09T14:10:03Z"}, {"author": "David Schinazi", "text": "

Yeah that's where my mind was going

", "time": "2022-11-09T14:10:23Z"}, {"author": "Daniel Gillmor", "text": "

CT: the IETF's blockchain of choice

", "time": "2022-11-09T14:10:24Z"}, {"author": "Nick Doty", "text": "

consistency of a resource does seem like a very general need; for example, is this site giving out different privacy policies?

", "time": "2022-11-09T14:10:25Z"}, {"author": "David Schinazi", "text": "

You could even do this with existing infrastructure by shoving it in a LetsEncrypt cert

", "time": "2022-11-09T14:11:04Z"}, {"author": "Martin Thomson", "text": "

signing with caching would address the consistency and correctness all in the one exchange

", "time": "2022-11-09T14:11:07Z"}, {"author": "Martin Thomson", "text": "

watch out for Richard, he will put all sorts of stuff in CT

", "time": "2022-11-09T14:11:35Z"}, {"author": "David Schinazi", "text": "

@MT What do you sign in that scenario?

", "time": "2022-11-09T14:11:40Z"}, {"author": "David Schinazi", "text": "

Just the key?

", "time": "2022-11-09T14:11:50Z"}, {"author": "Martin Thomson", "text": "

The server signs their config, the relay/proxy caches it

", "time": "2022-11-09T14:11:57Z"}, {"author": "Richard Barnes", "text": "

@david i may have designed that as a BT system for Mozilla that they never shipped https://wiki.mozilla.org/Security/Binary_Transparency

", "time": "2022-11-09T14:12:12Z"}, {"author": "Martin Thomson", "text": "

as we've established, the configuration - as a whole - needs to be consistent

", "time": "2022-11-09T14:12:19Z"}, {"author": "Richard Barnes", "text": "

(that = \"shove it in an LE cert\")

", "time": "2022-11-09T14:12:29Z"}, {"author": "David Schinazi", "text": "

:D

", "time": "2022-11-09T14:12:56Z"}, {"author": "David Schinazi", "text": "

You're evil Richard

", "time": "2022-11-09T14:13:03Z"}, {"author": "Richard Barnes", "text": "

stupid hacks are a core competency

", "time": "2022-11-09T14:13:24Z"}, {"author": "David Schinazi", "text": "

I prefer \"creative engineering\"

", "time": "2022-11-09T14:13:39Z"}, {"author": "Daniel Gillmor", "text": "

i definitely prefer stupid hacks to overly-clever hacks

", "time": "2022-11-09T14:14:04Z"}, {"author": "David Schinazi", "text": "

Oh for sure, ever time I thought I was clever I've regretted it later

", "time": "2022-11-09T14:14:46Z"}, {"author": "Martin Thomson", "text": "

ekr said \"blockchain\"

", "time": "2022-11-09T14:15:32Z"}, {"author": "David Schinazi", "text": "

drink

", "time": "2022-11-09T14:15:43Z"}, {"author": "Richard Barnes", "text": "

downforeveryoneorjustme.com

", "time": "2022-11-09T14:16:51Z"}, {"author": "Richard Barnes", "text": "

i probably need a more modern example than jQuery

", "time": "2022-11-09T14:19:17Z"}, {"author": "Nick Doty", "text": "

I feel like there's a lot of ./well-known resources that are supposed to be the same for everyone, and people shrug when they could be customized, or we talk about oracles, or we talk about how someone would notice and post about it somewhere

", "time": "2022-11-09T14:19:29Z"}, {"author": "Eric Rescorla", "text": "

@Nick Doty Blockchain

", "time": "2022-11-09T14:21:23Z"}, {"author": "Eric Rescorla", "text": "

More seriously, I do think a public merkle tree service would be valuable

", "time": "2022-11-09T14:21:39Z"}, {"author": "Eric Rescorla", "text": "

It doesn't need to be tied to CT

", "time": "2022-11-09T14:21:45Z"}, {"author": "Richard Barnes", "text": "

HTTP Resource Transparency (HRT)

", "time": "2022-11-09T14:22:05Z"}, {"author": "David Schinazi", "text": "

https://www.youtube.com/watch?v=zhWCnQoRyPo

\n
", "time": "2022-11-09T14:22:09Z"}, {"author": "Francesca Palombini", "text": "

thank you!

", "time": "2022-11-09T14:22:29Z"}, {"author": "Shivan Sahib", "text": "

thanks Sean and Martin!

", "time": "2022-11-09T14:22:46Z"}]