[bug] See if we can use the content
for posts, also when it's MFM.
#381
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#381
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Your setup
From source
Extra details
No response
Version
No response
PostgreSQL version
No response
What were you trying to do?
Generally when we send posts between servers, the content field uses html. As I understand it, with MFM we don't use the content because the content strips away the MFM.
If there's a difference in how Misskey (or w/e server sends the MFM) and Akkoma interprets MFM, we get a different view than what's expected. This happens for example with Misskey interpreting a newline as a line break, while Markdown doesn't.
It's also not consistent I believe. I assume we only do this for MFM.
Example post:
curl -Lv 'https://mk.toast.cafe/notes/98ycd9vc6b' -H 'Accept: application/activity+json' | jq .
What did you expect to happen?
I expect the html version from the content to be used. If the current way of stripping the html strips too much, then we should see if we can address it there. I'm unsure atm how easy, or even possible, that is though.
What actually happened?
We ignore the content and use the source content in some cases (at least MFM, not sure about other).
Logs
No response
Severity
I can manage
Have you searched for this issue?
Ref AkkomaGang/pleroma-fe#155 for context
Another reason to keep
content
, katex, https://snug.moe/notes/9azp4eandb 🥺cheat sheet at
/mfm-cheat-sheet
e.g. https://snug.moe/mfm-cheat-sheetI now understand why we do what we do. The problem is that the content doesn't contain the needed html. I made an issue for Foundkey now https://akkoma.dev/FoundKeyGang/FoundKey/issues/343.
The way I currently see it
fix_misskey_content
function in thePleroma.Web.ActivityPub.ObjectValidators.ArticleNotePageValidator
See if we can at least fix the newline issue. Maybe the markdown parser has an option which we can pass when doing MFM. Otherwise we can change the MFMParser to translateSee #478\n
to<br>
and see if it can work that way.I got some new awesome revelation on this. If we can figure out a proper way to represent using less complex html (see FoundKeyGang/FoundKey#343 ), then we can do the following and we don't have to wait on other software!
$[flip.h,v example]
into<span class="mfm-flip" data-mfm-h data-mfm-v>example</span>
(now it's<span style="display: inline-block; transform: scale(-1);">example</span>
, which is way more complex to get through the scrubber).source
with mediaTypetext/x.misskeymarkdown
so software who currently uses MFM can still re-parse and render this the way they always have.mfm_html: true
(other naming is also good, it's just an example)text/x.misskeymarkdown
.mfm_html: true
flag may eventually become obsolete.That way
Everybody wins 🎉
See my proposal for representing things at FoundKeyGang/FoundKey#343 (comment)
I'll wait a bit to see if there's feedback. Based on that, I'll see if I can actually get this implemented in Akkoma.