#nodeinfo — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #nodeinfo, aggregated by home.social.
-
Esos softwares compatibles con #ActivityPub que no tienen un #endpoint #nodeinfo, todo bien en casa?
-
@elgg We've got a MR to add #Elgg to fediverse.party;
https://codeberg.org/fediverse/fediparty/pulls/288
Our usual process is to set up some test accounts to check federation is working, and we usually wait until a project has at least 1 independent instance, to confirm that it's practical to self-host.
I can't find any Elgg instances on FediDB or the-federation.info, and only a demo server on fediverse.observer. Maybe that the plugin isn't publishing #NodeInfo data in a way these instance mapping sites can ingest?
-
@elgg We've got a MR to add #Elgg to fediverse.party;
https://codeberg.org/fediverse/fediparty/pulls/288
Our usual process is to set up some test accounts to check federation is working, and we usually wait until a project has at least 1 independent instance, to confirm that it's practical to self-host.
I can't find any Elgg instances on FediDB or the-federation.info, and only a demo server on fediverse.observer. Maybe that the plugin isn't publishing #NodeInfo data in a way these instance mapping sites can ingest?
-
@elgg We've got a MR to add #Elgg to fediverse.party;
https://codeberg.org/fediverse/fediparty/pulls/288
Our usual process is to set up some test accounts to check federation is working, and we usually wait until a project has at least 1 independent instance, to confirm that it's practical to self-host.
I can't find any Elgg instances on FediDB or the-federation.info, and only a demo server on fediverse.observer. Maybe that the plugin isn't publishing #NodeInfo data in a way these instance mapping sites can ingest?
-
@elgg We've got a MR to add #Elgg to fediverse.party;
https://codeberg.org/fediverse/fediparty/pulls/288
Our usual process is to set up some test accounts to check federation is working, and we usually wait until a project has at least 1 independent instance, to confirm that it's practical to self-host.
I can't find any Elgg instances on FediDB or the-federation.info, and only a demo server on fediverse.observer. Maybe that the plugin isn't publishing #NodeInfo data in a way these instance mapping sites can ingest?
-
Just so you know, the dominance of Mastodon as a server software choice for the fediverse has at times been overstated, and may still be overstated;
"The Mastodon API endpoint is Mastodon specific but platforms which have also implemented the Mastodon API (to make use of Mastodon mobile clients) look like Mastodon servers to apps reading information about the servers."
@jaywink, 2019
https://talk.feneas.org/t/serviceinfo-specification-for-service-metadata/99
(1/2)
-
Just so you know, the dominance of Mastodon as a server software choice for the fediverse has at times been overstated, and may still be overstated;
"The Mastodon API endpoint is Mastodon specific but platforms which have also implemented the Mastodon API (to make use of Mastodon mobile clients) look like Mastodon servers to apps reading information about the servers."
@jaywink, 2019
https://talk.feneas.org/t/serviceinfo-specification-for-service-metadata/99
(1/2)
-
Just so you know, the dominance of Mastodon as a server software choice for the fediverse has at times been overstated, and may still be overstated;
"The Mastodon API endpoint is Mastodon specific but platforms which have also implemented the Mastodon API (to make use of Mastodon mobile clients) look like Mastodon servers to apps reading information about the servers."
@jaywink, 2019
https://talk.feneas.org/t/serviceinfo-specification-for-service-metadata/99
(1/2)
-
Just so you know, the dominance of Mastodon as a server software choice for the fediverse has at times been overstated, and may still be overstated;
"The Mastodon API endpoint is Mastodon specific but platforms which have also implemented the Mastodon API (to make use of Mastodon mobile clients) look like Mastodon servers to apps reading information about the servers."
@jaywink, 2019
https://talk.feneas.org/t/serviceinfo-specification-for-service-metadata/99
(1/2)
-
Edit: 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 🔥
-
Edit: 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 🔥
-
Edit: 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 🔥
-
Edit: 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 🔥
-
Edit: 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 🔥
-
@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:- 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 -
@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:- 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 -
@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:- 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 -
@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:- 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 -
@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:- 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 -
FEP-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.
-
FEP-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.
-
FEP-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.
-
FEP-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.
-
I 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.
-
I 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.
-
I 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.
-
I 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.
-
I 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.
-
@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 -
@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 -
@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 -
-
-
-
-
-
We'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 NodeInfosoftware.versionfield will be changed from theSemVertype to a plainstringto 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 usingfederation.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.
-
We'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 NodeInfosoftware.versionfield will be changed from theSemVertype to a plainstringto 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 usingfederation.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.
-
We'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 NodeInfosoftware.versionfield will be changed from theSemVertype to a plainstringto 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 usingfederation.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.
-
We'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 NodeInfosoftware.versionfield will be changed from theSemVertype to a plainstringto 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 usingfederation.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.
-
We'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 NodeInfosoftware.versionfield will be changed from theSemVertype to a plainstringto 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 usingfederation.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.
-
Started writing a new FEP:
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Mentioned some best practices. What else should be added there?
-
Started writing a new FEP:
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Mentioned some best practices. What else should be added there?
-
Started writing a new FEP:
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Mentioned some best practices. What else should be added there?
-
Started writing a new FEP:
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Mentioned some best practices. What else should be added there?
