dansupEdit: Done! https://madeincanada.social/#servers
Instead of manually adding servers to https://MadeInCanada.social, I'll leverage my FediDB.com service with a new API 🔥
KipJayChou
Jupiter Rowland@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:
- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo
silverpillFEP-0151: NodeInfo in Fediverse Software (2025 edition)
I added the "Implementations" section and a reference to FEP-844e:
https://codeberg.org/fediverse/fep/pulls/741
There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.
If you have any suggestions, please comment here, on SocialHub, or create an issue.
Justin ThomasI finally got around to setting up #nodeinfo properly on #Enigmatick as an effort to be a more compliant #ActivityPub participant. Coincidentally (and unexpectedly), my connected instances have jumped substantially (>15% in 24 hours):
enigmatick=> SELECT CASE WHEN created_at > NOW() - INTERVAL '1 day' THEN 'last 24h' WHEN created_at > NOW() - INTERVAL '2 days' THEN '24-48h ago' WHEN created_at > NOW() - INTERVAL '3 days' THEN '48-72h ago' END as period, COUNT(*) FROM instances WHERE created_at > NOW() - INTERVAL '3 days' GROUP BY period ORDER BY period;
period | count
------------+-------
24-48h ago | 1
48-72h ago | 3
last 24h | 164
(3 rows)
Maybe it's not directly related - I also fixed some direct object and tags link references to provide proper ActivityPub representations.
Blain SmithRequest to add
https://github.com/jhass/nodeinfo/issues/107
#ActivityPub #NodeInfo #ContentModeration
mods to the NodeInfo spec so we can all know how many moderators are handing content moderation on any given instance in the fediverse. The idea came from @jwildeboer@social.wildeboer.net wanting to know the ratio of mods:users on a instance.https://github.com/jhass/nodeinfo/issues/107
#ActivityPub #NodeInfo #ContentModeration
@crossgolf_rebel - kostenlose Kwalitätsposts Wahrscheinlich auch ein Grund, warum (streams) und Forte so sind, wie sie sind:
Bei (streams) hat Mike nodeinfo mit Absicht komplett rausgeschmissen. Forte hat wieder nodeinfo, weil das laut Mike in einem mastodondominierten Fediverse zwingend notwendig ist. Aber Forte meldet alle Statistikwerte als 0. Auch da kann man von Absicht ausgehen.
Während also Hubzilla die Statistiken mit nomadischen Kanälen verzerrt, weil jeder Klon als eigenes Konto aufgefaßt wird, gleichzeitig aber auch jeder einzelne Kanal auf demselben Konto wiederum als eigenes Konto gezählt wird (Hubzilla meldet ja zum Glück nicht die Zahl der Konten, sondern die Zahl der Kanäle), tauchen (streams) und Forte in den Statistiken überhaupt nicht auf.
Interessanterweise meldet Forte auch keine Versionsnummern per nodeinfo, sondern nur auf Wegen, die nur von Mikes eigener Software verstanden werden. So kann man zwar auf Community-Listen auf (streams) und Forte die Versionsnummern einzelner Server sehen, aber Crawler, die auf ActivityPub und Mastodon ausgelegt sind, erfahren die Versionsnummern nicht.
Dazu kommt, daß (streams) ohne nodeinfo nicht crawlbar ist. Selbst wenn es nodeinfo hätte, wäre es nicht crawlbar, weil es als einzige Fediverse-Software keinen festen, einheitlichen Softwarenamen hat. Und so ist (streams) vom Fediverse Observer und vom FediIndex komplett abwesend. Die FediDB, auf der Daniel jede Software per Hand einträgt, kennt nicht nur (streams) nicht, sondern auch Forte.
Zugegeben, statistische Signifikanz fürs Fediverse als Ganzes haben die beiden nicht. (streams) dürfte keine 50 aktiven Nutzer haben, Forte keine 20, die sich samt und sonders aus den (streams)-Reihen rekrutiert haben dürften. Und Forte hat nur Privatserver, aber keinen einzigen öffentlichen mit offener Registrierung, während (streams) zumindest davon zwei hat, die aber nur Insider kennen.
CC: @Netzbegrünung
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #nodeinfo
Bei (streams) hat Mike nodeinfo mit Absicht komplett rausgeschmissen. Forte hat wieder nodeinfo, weil das laut Mike in einem mastodondominierten Fediverse zwingend notwendig ist. Aber Forte meldet alle Statistikwerte als 0. Auch da kann man von Absicht ausgehen.
Während also Hubzilla die Statistiken mit nomadischen Kanälen verzerrt, weil jeder Klon als eigenes Konto aufgefaßt wird, gleichzeitig aber auch jeder einzelne Kanal auf demselben Konto wiederum als eigenes Konto gezählt wird (Hubzilla meldet ja zum Glück nicht die Zahl der Konten, sondern die Zahl der Kanäle), tauchen (streams) und Forte in den Statistiken überhaupt nicht auf.
Interessanterweise meldet Forte auch keine Versionsnummern per nodeinfo, sondern nur auf Wegen, die nur von Mikes eigener Software verstanden werden. So kann man zwar auf Community-Listen auf (streams) und Forte die Versionsnummern einzelner Server sehen, aber Crawler, die auf ActivityPub und Mastodon ausgelegt sind, erfahren die Versionsnummern nicht.
Dazu kommt, daß (streams) ohne nodeinfo nicht crawlbar ist. Selbst wenn es nodeinfo hätte, wäre es nicht crawlbar, weil es als einzige Fediverse-Software keinen festen, einheitlichen Softwarenamen hat. Und so ist (streams) vom Fediverse Observer und vom FediIndex komplett abwesend. Die FediDB, auf der Daniel jede Software per Hand einträgt, kennt nicht nur (streams) nicht, sondern auch Forte.
Zugegeben, statistische Signifikanz fürs Fediverse als Ganzes haben die beiden nicht. (streams) dürfte keine 50 aktiven Nutzer haben, Forte keine 20, die sich samt und sonders aus den (streams)-Reihen rekrutiert haben dürften. Und Forte hat nur Privatserver, aber keinen einzigen öffentlichen mit offener Registrierung, während (streams) zumindest davon zwei hat, die aber nur Insider kennen.
CC: @Netzbegrünung
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #nodeinfo
grindholdyeaaaah i implemented #nodeinfo in #flohmarkt. now how the hell does one add a server to #fedidb in the year 2025? :D
Fedify: ActivityPub server frameworkWe'd like to recognize the valuable contributions from two developers who participated in Korea's #OSSCA (Open Source Contribution Academy) program. Both contributors identified important gaps in #Fedify's functionality and documentation, providing thoughtful solutions that benefit the broader #ActivityPub ecosystem.
@gaebalgom contributed PR #365, addressing issue #353 regarding NodeInfo parser compatibility, originally reported by @andypiper. The issue arose when Fedify incorrectly rejected #NodeInfo documents from snac instances due to overly strict version string parsing that required semantic versioning compliance. Their solution improves the fallback behavior in the parseSoftware() function to handle non-SemVer version strings by parsing dot-separated numbers and defaulting to zero for missing components. The implementation includes thorough test coverage for various edge cases, including single numbers (3), two-part versions (2.81), and malformed version strings. This fix provides immediate compatibility improvements across the fediverse while maintaining backward compatibility, and will be included in Fedify 1.9. The contribution serves as an interim solution, with a more comprehensive fix planned for Fedify 2.0 (issue #366), where the NodeInfo software.version field will be changed from the SemVer type to a plain string to fully comply with the NodeInfo specification.
@z9mb1 contributed PR #364, resolving issue #337 by adding practical examples for Fedify's custom collection dispatchers feature. Custom collections were introduced in Fedify 1.8 but lacked clear documentation for developers seeking to implement them. Their contribution provides a comprehensive example demonstrating how to set up custom collections for tagged posts, including proper routing patterns, pagination handling, and counter functionality. The example includes mock data structures, shows how to configure collection dispatchers with URL patterns like /users/{userId}/tags/{tag}, and demonstrates the complete request/response cycle using federation.fetch(). This work provides developers with a clear, runnable reference that reduces the complexity of implementing custom collections in ActivityPub applications.
We appreciate these meaningful contributions that help make Fedify more accessible and robust for the entire ActivityPub community.
