# orderedItems[].object.content
@Astromeg I added it a couple of weeks ago. Just bear in mind users from other less nerdy mastodon instances won't see it unless you choose the unicode option. I'm considering adding support to attach images with rendered LaTeX to make this more universal.

# orderedItems[].object.contentMap.en
@Astromeg I added it a couple of weeks ago. Just bear in mind users from other less nerdy mastodon instances won't see it unless you choose the unicode option. I'm considering adding support to attach images with rendered LaTeX to make this more universal.

# orderedItems[].object.content
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily That's not to say this isn't a useful and valid discussion, I just don't think these points will solve AP's deeper issues.

# orderedItems[].object.contentMap.en
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily That's not to say this isn't a useful and valid discussion, I just don't think these points will solve AP's deeper issues.

# orderedItems[].object.content
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

Looking at the key issues discussed, I am not sure I'm thinking in the same direction. These suggestions feel like they're more focused on the UX of implementations, and not addressing shortcomings of AP as a protocol. I am generally aligned with what @jenniferplusplus is saying, particularly the lack of stated goals being the main driver of divergence in implementation. Adding more client capabilities just hides the fact there's no accepted answer here.

# orderedItems[].object.contentMap.en
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

Looking at the key issues discussed, I am not sure I'm thinking in the same direction. These suggestions feel like they're more focused on the UX of implementations, and not addressing shortcomings of AP as a protocol. I am generally aligned with what @jenniferplusplus is saying, particularly the lack of stated goals being the main driver of divergence in implementation. Adding more client capabilities just hides the fact there's no accepted answer here.

# orderedItems[].object.content
@lily @kopper @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate That's what I don't get. E2EE is a client capability. I guess my view is that there's way too much metadata in the process of federation to provide meaningful privacy for DMs other than encrypting the content of a message, and you can't trust a server to sign requests on behalf of a client.

# orderedItems[].object.contentMap.en
@lily @kopper @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate That's what I don't get. E2EE is a client capability. I guess my view is that there's way too much metadata in the process of federation to provide meaningful privacy for DMs other than encrypting the content of a message, and you can't trust a server to sign requests on behalf of a client.

# orderedItems[].object.content
@benpate @hrefna @jenniferplusplus @kopper @puppygirlhornypost2 @lily

So the verification question bugs me. The only verifiable unit of trust without e2ee and a full public key infrastructure is the server. So signing individual messages is wasteful, as if you don't trust the server you can't trust any actor on it, and if you trust the server you have to trust the actors on it implicitly.

We already have a mechanism to trust servers: it's TLS and cert chain of trust. Anything else is decorative.

I don't see how end-to-end encryption is useful in a social network, which is a whole different problem space, so I would strongly advocate for trust and verification at the server level, and using SSL.

I'm open to the idea that there are use cases I don't see here, but if so they should be clearly documented as goals for a future protocol.

# orderedItems[].object.contentMap.en
@benpate @hrefna @jenniferplusplus @kopper @puppygirlhornypost2 @lily

So the verification question bugs me. The only verifiable unit of trust without e2ee and a full public key infrastructure is the server. So signing individual messages is wasteful, as if you don't trust the server you can't trust any actor on it, and if you trust the server you have to trust the actors on it implicitly.

We already have a mechanism to trust servers: it's TLS and cert chain of trust. Anything else is decorative.

I don't see how end-to-end encryption is useful in a social network, which is a whole different problem space, so I would strongly advocate for trust and verification at the server level, and using SSL.

I'm open to the idea that there are use cases I don't see here, but if so they should be clearly documented as goals for a future protocol.

# orderedItems[].object.content
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

(Long reply follows, possibly breaking your client implementation?)

- Lack of reference implementation. A spec without a reference implementation or usable test suite hands control of the spec to the largest implementer.
- Lack of easy extensibility. A successor needs a clearly documented capability for extensions.
- Lack of opinion on implementation. This is a controversial one, but leads to implementations that are spec-conformant but not interoperable. The spec should provide a baseline set of operations that may/must be implemented upon receiving a message, with a set of expected responses.
- Feature discoverability. When your protocol allows for wildly different implementations, feature discovery is essential to allow interoperability. This allows servers to negotiate for the largest implemented subset of features instead of defensively assuming the smallest.
- Trust at the server level. A server verifies actors it owns, no individual certs. The verification mechanism must be baked into the spec and not left to implementers.
- Batching.
- Doesn't utulise HTTP effectively. ActivityPub mandates HTTPS as a transport protocol but does not mandate use of HTTP features such as response codes. This is a must-fix for operational scaling.
- Client API. C2S is almost impossible to implement. A replacement should be an optional, lightweight, minimum-surface REST API.

# orderedItems[].object.contentMap.en
@benpate @puppygirlhornypost2 @hrefna @jenniferplusplus @lily

(Long reply follows, possibly breaking your client implementation?)

- Lack of reference implementation. A spec without a reference implementation or usable test suite hands control of the spec to the largest implementer.
- Lack of easy extensibility. A successor needs a clearly documented capability for extensions.
- Lack of opinion on implementation. This is a controversial one, but leads to implementations that are spec-conformant but not interoperable. The spec should provide a baseline set of operations that may/must be implemented upon receiving a message, with a set of expected responses.
- Feature discoverability. When your protocol allows for wildly different implementations, feature discovery is essential to allow interoperability. This allows servers to negotiate for the largest implemented subset of features instead of defensively assuming the smallest.
- Trust at the server level. A server verifies actors it owns, no individual certs. The verification mechanism must be baked into the spec and not left to implementers.
- Batching.
- Doesn't utulise HTTP effectively. ActivityPub mandates HTTPS as a transport protocol but does not mandate use of HTTP features such as response codes. This is a must-fix for operational scaling.
- Client API. C2S is almost impossible to implement. A replacement should be an optional, lightweight, minimum-surface REST API.

# orderedItems[].object.content
@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate One way out of this particular chicken-and-egg conundrum is to provide a reference translation layer or proxying client that will provide compatibility with AP whilst allowing implementers time to migrate. Then you can make decisions about what subset of features to expose without having to burden your protocol with compatibility. Experience with AP suggests to me there's significant value in reference implementations.

# orderedItems[].object.contentMap.en
@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate One way out of this particular chicken-and-egg conundrum is to provide a reference translation layer or proxying client that will provide compatibility with AP whilst allowing implementers time to migrate. Then you can make decisions about what subset of features to expose without having to burden your protocol with compatibility. Experience with AP suggests to me there's significant value in reference implementations.

# orderedItems[].object.content
@juandesant @mansr It's from the Mathstodon customisations that add Latex support. I believe it was chosen as it's Ramanujan's number, the smallest number than can be expressed as the sum of 2 cubic numbers, in 2 different ways.

# orderedItems[].object.contentMap.en
@juandesant @mansr It's from the Mathstodon customisations that add Latex support. I believe it was chosen as it's Ramanujan's number, the smallest number than can be expressed as the sum of 2 cubic numbers, in 2 different ways.

# orderedItems[].object.content
At some point overnight the cached version of the mastodon service worker expired, and the whole mastodon web frontend stopped working.

None of the hosting alarms went off, because everything *except* this one javascript file was working. Unfortunately the whole website depends on one javascript file, which is misconfigured in the Mastodon docs for setting up a site with docker compose.

Cue some rapid changes to the hosting setup for a single file. 🙄

Hopefully we're coming to the end of the Learning Through Painful Mistakes phase and this should now be working for everyone.

But please, if images are not loading (and clearing cache doesn't help) do keep letting me know so I can dig into it further and help the Mastodon team fix this problem.

# orderedItems[].object.contentMap.en
At some point overnight the cached version of the mastodon service worker expired, and the whole mastodon web frontend stopped working.

None of the hosting alarms went off, because everything *except* this one javascript file was working. Unfortunately the whole website depends on one javascript file, which is misconfigured in the Mastodon docs for setting up a site with docker compose.

Cue some rapid changes to the hosting setup for a single file. 🙄

Hopefully we're coming to the end of the Learning Through Painful Mistakes phase and this should now be working for everyone.

But please, if images are not loading (and clearing cache doesn't help) do keep letting me know so I can dig into it further and help the Mastodon team fix this problem.

# orderedItems[].object.content
Okay, I didn't fix images but MathJax (LaTeX) support is now working. Click the little 𝑓(𝑥) button and go crazy 👩‍🔬

𝑒²=𝑚²𝑐⁴+𝑝²𝑐²

Please be aware that it only works in the web interface, and it's best to convert to unicode if you want other instances to see it rendered.

# orderedItems[].object.contentMap.en
Okay, I didn't fix images but MathJax (LaTeX) support is now working. Click the little 𝑓(𝑥) button and go crazy 👩‍🔬

𝑒²=𝑚²𝑐⁴+𝑝²𝑐²

Please be aware that it only works in the web interface, and it's best to convert to unicode if you want other instances to see it rendered.

# orderedItems[].object.content
Running into so many issues with Mastodon that aren't fixed yet - and which realistically the only way to fix are to fork mastodon and maintain it myself - has triggered me to go build an ActivityPub implementation without the arcane incantations necessary to manage the eldritch horror of scaling a react app running on rails.

# orderedItems[].object.contentMap.en
Running into so many issues with Mastodon that aren't fixed yet - and which realistically the only way to fix are to fork mastodon and maintain it myself - has triggered me to go build an ActivityPub implementation without the arcane incantations necessary to manage the eldritch horror of scaling a react app running on rails.

# orderedItems[].object.content
@juandesant It means for now no more maintenance, unless I find a way to trigger a fix for the missing images.

# orderedItems[].object.contentMap.en
@juandesant It means for now no more maintenance, unless I find a way to trigger a fix for the missing images.

# orderedItems[].object.content
There are several bug reports for this on Mastodon going back over a year and no fixes. Worst case scenario the cache expires in 3 more days and images should load then.

Until then, if you do have missing images, you'll need to unregister the sw.js service worker in your browser and restart your browser to fix the problem.

Chrome: https://www. connecto.io/kb/knwbase/how-to-unregister-service-worker-in-chrome/
Safari: Settings > Privacy > Manage Website Data
Firefox: goto about:debugging and click unregister for astrodon.social

# orderedItems[].object.contentMap.en
There are several bug reports for this on Mastodon going back over a year and no fixes. Worst case scenario the cache expires in 3 more days and images should load then.

Until then, if you do have missing images, you'll need to unregister the sw.js service worker in your browser and restart your browser to fix the problem.

Chrome: https://www. connecto.io/kb/knwbase/how-to-unregister-service-worker-in-chrome/
Safari: Settings > Privacy > Manage Website Data
Firefox: goto about:debugging and click unregister for astrodon.social

# orderedItems[].object.content
Apologies for the downtime on Astrodon earlier. Updating the Mastodon build to fix the missing media problem didn't work and rolling back failed.

Everything is back to normal now, but realistically there's no way to remotely trigger the serviceworker refresh needed to fix missing images.

# orderedItems[].object.contentMap.en
Apologies for the downtime on Astrodon earlier. Updating the Mastodon build to fix the missing media problem didn't work and rolling back failed.

Everything is back to normal now, but realistically there's no way to remotely trigger the serviceworker refresh needed to fix missing images.

# orderedItems[].object.content
@PWei888 can you check if images are coming from media.astrondon.social? If so you'll need to go into firefox dev tools and under Application > Service Workers unregister "sw.js". Then quit and restart your browser. Apologies - it's an issue with Mastodon when moving the media to a different host.

# orderedItems[].object.contentMap.en
@PWei888 can you check if images are coming from media.astrondon.social? If so you'll need to go into firefox dev tools and under Application > Service Workers unregister "sw.js". Then quit and restart your browser. Apologies - it's an issue with Mastodon when moving the media to a different host.

# orderedItems[].object.content
@juandesant no, image uploads appear to be working. I can't see any log errors from a failed upload attempt either

# orderedItems[].object.contentMap.en
@juandesant no, image uploads appear to be working. I can't see any log errors from a failed upload attempt either

# orderedItems[].object.content
@juandesant I just made a config change that might have fixed things. What happens if you reload on mobile?

# orderedItems[].object.contentMap.en
@juandesant I just made a config change that might have fixed things. What happens if you reload on mobile?

# orderedItems[].object.content
Quick poll - are you still having issues with images on Astrodon.social using the web interface?

# orderedItems[].object.contentMap.en
Quick poll - are you still having issues with images on Astrodon.social using the web interface?

# orderedItems[].object.content
@TMEubanks see announcements. You need to clear your browser cache - particularly any service workers - and restart your browser due to the way mastodon works.

# orderedItems[].object.contentMap.en
@TMEubanks see announcements. You need to clear your browser cache - particularly any service workers - and restart your browser due to the way mastodon works.