hhmx.de
rozenglass@fedi.dreamscape.link
rozenglass@fedi.dreamscape.link

Red Rozenglass

(@rozenglass@fedi.dreamscape.link)

Do 06.03.2025

Beiträge: 9Folgt: 0Folgende: 0

a young man from a far away land.
corposlave ("software engineering consultant" lol).

GNU/Linux (Slackware). Programming (C, sh, Lisp, Lua, Web, JS, etc.). Likes writing documentation, understanding & maintaining systems, archiving, organization. Interested in paper machines, books, visual novels, writing, drawing, anime. EN/AR fluent, TR can order food, JP early learnings.

RƎD.


Website

https://dreamscape.link/

PGP Fingerprint

0BEB A81D 9E51 F58F 7E40 78B8 CFC8 26D6 A116 A778

Current Account

https://fedi.dreamscape.link/rozenglass

Backup Account

https://mstdn.io/@rozenglass

Dead Account (1)

https://anime.website/rozenglass

Dead Account (2)

https://letsalllovela.in/rozenglass

OCEAN

O+++C+E-A++N++

MBTI

INFJ

Ψ

RƎD

fedi.dreamscape.link · snac

Föderation · Sa 22.03.2025 03:01:09

Added browser caching over my instance, for better user experience with all the files being proxied from other instances. Apache configs (requires enabling mod_headers if you don't have it already):

    <If "%{REQUEST_URI} =~ m#^/[^/]+/(s|x|y)/.+$# || %{REQUEST_URI} =~ m#^.*\.ico$#">
Header set Cache-Control "max-age=172800, public, immutable, must-revalidate"
</If>
The last .ico part is not necessarily snac related obviously :3

Föderation · Fr 21.03.2025 11:51:08

@grunfink@comam.es I hear you're taking a break from snac, to whom should I direct potential future patches?

I have a simpler one this time :)

Allow custom FROM address for email notifications
https://dreamscape.link/vault/public/debug/snac2/0003-Allow-custom-FROM-address-for-email-notifications.patch

Föderation · Fr 14.03.2025 20:42:32

@grunfink@comam.es I noticed some posts missing their images. This happens because some attachment images are skipped if the body of the message contained a link to the picture. See this post for example:

https://dreamscape.link/vault/public/debug/snac2/4beb5a0d464e4ad952b192f0403635ea.json

I would rather see duplicate attachments, than miss some attachments completely. This patch removes the duplication check until a smarter detection solution is made (I'm not working on one for now):

Remove faulty attachments deduplication mechanism
Attachments are skipped if they are already included
in the post content, but this sometimes mistakenly
skips images if the post content includes an anchor
that links to the image too. I'd rather see some
duplicate attachments than miss them.
https://dreamscape.link/vault/public/debug/snac2/0002-Remove-faulty-attachments-deduplication-mechanism.patch


In an unrelated matter, I prefer the mentions to look like they do on X, Pleroma, and Mastodon, i.e. at the start of the post, without CC:, and including the replied to user. I wrote the following patch to make it that way. This solves my issue. If you're interested, I can perhaps make it a user option, to allow users to choose their mention style.
Switch to mainstream micro-blogging mentions style
* Mention the replied-to message owner when replying to them.
* Remove the "CC:" and put the mentions at the beginning.
https://dreamscape.link/vault/public/debug/snac2/0001-Switch-to-mainstream-micro-blogging-mentions-style.patch


(Anyone is free to apply and use those patches,
under the same current licensing terms as snac2).

Föderation · Mi 12.03.2025 20:22:29

@grunfink@comam.es Hello, Grünfink, I've been facing an issue where friends from different instances (Pleroma mostly?) appear to unfollow me, but they confirm that they really didn't. I suspect commit e9f391e "Added a special check for Undo + Follow.", in which activitypub.c is modified as follows:

     if (strcmp(type, "Undo") == 0) { /** **/
+ if (xs_type(object) != XSTYPE_DICT)
+ utype = "Follow";
+
It seems that it treats all messages of type 'Undo', where 'object' is not a dict, to be a utype 'Follow' by default. But that does not seem to be necessarily correct; there are messages that are not like that. This notification JSON for example shows a message that was likely overridden to be utype 'Follow', but originally wasn't. I confirmed with friendo that they didn't unfollow me. My account is not even in the 'to' field, which is a thing I noticed with all such mistaken unfollows (I have some 5 or 6 so far, in a few days):

https://dreamscape.link/vault/public/debug/snac2/1741791872.179863.json

Compare with this object, which is a real Pleroma unfollow I intentionally made:

https://dreamscape.link/vault/public/debug/snac2/1741805474.188476.json

Any thoughts or ideas? I'm familiar with C, but not enough with ActivityPub to know what is happening in this case. A quick solution that comes to mind, based on the handful of objects I've seen so far, is to check whether we're in the 'to' field before overriding the utype, but I have no idea why this whole utype override exists in the first place.