Ryan Barrett

Hmm. What are you searching for in Mastodon? I see it when I search for @[email protected] on https://indieweb.social/ : Here's your Bridgy Fed user page: https://fed.brid.gy/bsky/georgvo.bsky.social

Ah, yeah, this is a confusing Mastodon wart: if you're not logged in, search only shows you profile, posts, etc that the server already has stored locally, it doesn't resolve...

For when I do come back to this, these are the errors we saw in prod: * https://console.cloud.google.com/errors/detail/CL6Jzu_r-6aThQE;time=P7D;locations=global?project=bridgy-federated * https://console.cloud.google.com/errors/detail/CIGJnbnCq7fm1gE;time=P7D;locations=global?project=bridgy-federated * https://console.cloud.google.com/errors/detail/COq0kKuXvvyXsgE;time=P7D;locations=global?project=bridgy-federated

Alternatively, migrating to jetstream might obviate this? #1491

I'm confused about the original problem here. Yes we have `Object`s stored with base32-encoded string CIDs in `bsky`, and if we upgrade, new `Object`s would have bytes CIDs in `bsky`...

Also, I ported arroba's `subscribe.py` to `libipld.decode_car` for parsing `payload['blocks']` just now, and ran it with v1 vs v3 and compared, and the CID-valued fields in the MST blocks are...

Original upgrade commit was 9ba6bdf37d1e17199807f271bcfeee4354399406

Since I originally wrote this, I switched receive tasks from using stored `Object`s to HTTP request parameters, which need to be URL-encoded ASCII. So, one solution is, in `atproto_firehose.handle`, before...

Woo, it's working!

Definitely, the DM would need to come from a different account, eg @[email protected].