On my client, it’s all expanded and I see all the formatting characters.
Ah dang, that’s good to know (though I’m not sure what to do as an alternative) — I was unaware that the collapsible spoilers weren’t supported on Boost. I guess that means that Lemmy’s markdown formatting hasn’t entirely been standardized across the service. I personally have encountered some inconsistency on the Tesseract UI with CommonMark Autolink [2] formatting where the autolinks don’t even render [1].
I recommend reporting this to the Boost devs to improve Markdown feature compatibility between them and the Lemmy UI.
Signal isn't federated ^[1][2][3.1]^; it's decentralized ^[1][2][3.2]^. Though, for all practical purposes, I would generally argue that it's centralized.
::: spoiler References
1. Signal-Server. signalapp. Github. Published: 2025-01-31T15:34:14.000Z. Accessed: 2025-02-01T09:24Z. <https://github.com/signalapp/Signal-Server>.
- This is the source code for the server that Signal uses.
2. "Signal (software)". Wikipedia. Published: 2025-01-06T09:34Z. Accessed: 2025-02-1T09:30Z. <https://en.wikipedia.org/wiki/Signal_(software)>.
- ¶"Architecture". ¶"Servers".
> Signal relies on centralized servers that are maintained by Signal Messenger. In addition to routing Signal's messages, the servers also facilitate the discovery of contacts who are also registered Signal users and the automatic exchange of users' public keys. […]
3. "Reflections: The ecosystem is moving". moxie0. Signal Blog. Published: 2016-05-10. Accessed: 2025-02-01T09:40Z. <https://signal.org/blog/the-ecosystem-is-moving/>.
1. ¶5. to ¶"Stuck in time". ¶3-6
> One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all. […] [interoperable protocols] [have] taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving. […] Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.
2. ¶"Stuck in time". "Federation and control". ¶6.
> An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do.
:::
Rendered:
In the rendered text there are no links; however, there should be links at the end, as is shown by the CommonMark autolinks in the raw text.
Bro put citations in his lemmy comment 💀
I do my best to cite any claim that I make. I would encourage others to do the same.
I wish more people did that ngl 💀
Based.
I wish Boost understood the collapsible spoilers.
On my client, it’s all expanded and I see all the formatting characters. It looks/works great in a browser though.
Ah dang, that’s good to know (though I’m not sure what to do as an alternative) — I was unaware that the collapsible spoilers weren’t supported on Boost. I guess that means that Lemmy’s markdown formatting hasn’t entirely been standardized across the service. I personally have encountered some inconsistency on the Tesseract UI with CommonMark Autolink [2] formatting where the autolinks don’t even render [1].
I recommend reporting this to the Boost devs to improve Markdown feature compatibility between them and the Lemmy UI.
References
Signal isn't federated ^[1][2][3.1]^; it's decentralized ^[1][2][3.2]^. Though, for all practical purposes, I would generally argue that it's centralized. ::: spoiler References 1. Signal-Server. signalapp. Github. Published: 2025-01-31T15:34:14.000Z. Accessed: 2025-02-01T09:24Z. <https://github.com/signalapp/Signal-Server>. - This is the source code for the server that Signal uses. 2. "Signal (software)". Wikipedia. Published: 2025-01-06T09:34Z. Accessed: 2025-02-1T09:30Z. <https://en.wikipedia.org/wiki/Signal_(software)>. - ¶"Architecture". ¶"Servers". > Signal relies on centralized servers that are maintained by Signal Messenger. In addition to routing Signal's messages, the servers also facilitate the discovery of contacts who are also registered Signal users and the automatic exchange of users' public keys. […] 3. "Reflections: The ecosystem is moving". moxie0. Signal Blog. Published: 2016-05-10. Accessed: 2025-02-01T09:40Z. <https://signal.org/blog/the-ecosystem-is-moving/>. 1. ¶5. to ¶"Stuck in time". ¶3-6 > One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all. […] [interoperable protocols] [have] taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving. […] Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing. 2. ¶"Stuck in time". "Federation and control". ¶6. > An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do. :::Same with Sync, unfortunately.
Dang 😕. See my comment for a related response.
I recommend reporting the bug to the Sync devs to fix their Markdown formatting to improve feature compatibility between them and the Lemmy UI.
That person isn’t fucking around.
I take the issue of misinformation seriously. I try to be the change that I wish to see.