Add new blog post "67 perc providers support APIv2"

content/blog/2024-08-01_67_percent_providers_support_APIv2.md

@@ -0,0 +1,132 @@
+---
+title: 67% of the listed XMPP providers use support API v2
+date: 2024-08-01
+---
+
+Six months after we have offered hosting a [generic JSON files](https://providers.xmpp.net/provider-file-generator/) which are based on our API version 2, 67% of the listed XMPP service providers on their XMPP instance.
+This is a great achievement for decentralization in XMPP onboarding but beyond the project goals draws the road to better transparency, quality and understanding of the entire XMPP network.
+
+In total we have 72 XMPP providers listed in our setup. By end of 2024 we aim to cross the 100, maybe even 150.
+But this is just a very small percentage of the [existing instances](https://xmppnetwork.goodbytes.im). out there. Our main static shows that about 60% of the listed servers are categorized in D.
+This is of course unfortunate.
+The main reasons are either closed registrations, missing information or both.
+We recommend to also support the automated way we have established.
+
+## Perspective &  Criticism
+
+First of all, big thanks to all the supporters and applies of our projects and the helpful and constructive and last but not least welcome feedback.
+We really did our best to apply and adapt in the exploitative sphere we are in.
+Since we started about four years ago there have always been confronted criticism, which we also expected:
+- The rating was expected as major source of strong criticism
+- Boycott of the service
+- Abusive behavior
+Though, some criticism we certainly did not expect.
+In general, we do understand, but I would like to invite you to take a very certain perspective: The users and newcomers to XMPP.
+
+What do we know what they know?
+What do we know what they understand?
+The distances, between our highly tech-savvy knowledge and this of the majority of the users we often build our services and software for is huge.
+Even more, the tolerance of these people is often very thin.
+As thin as is your tolerance is maybe with the limits and threshold we have defined to rate your server setup.
+The perspective we take is to ensure a good experience right after registering to an XMPP server.
+At least, the server should not be part of any issue.
+
+When it comes to the rating parameter minimum, limits and threshold we have defined, we usually went through long and reiterating discussions that partly have not yet even come to settle.
+The main focus is the question how for example too low parameter for HTTP file upload could affect the user experience.
+If you believe 5 MB are enough, then you have not have the situation that maybe some client does not compress.
+Videos reach sizes that exceed this easily by the factor of 10.
+Is this good? Is this something you should care about?
+Well, you run a public server and have some responsibility and, to our understanding, most providers are interested to have more users.
+This is why we argued to have a minimum of 20 MB for example.
+It is certainly not sufficient in all cases, but it will cover almost all of the usual transferred sizes and ensures a good experience.
+If you disagree, that is fine, this is why we love decentralization.
+However, then it is maybe not the best to registers newcomer that have certain expectations right away to your server.
+Sorry to say, but especially public server maintainers have and have show the potential to ruin the user experience and reputation of the network and also your XMPP apps.
+
+Some discussion required us to create more distinct parameters that now may bug you.
+And that just because we hit reality of the decentralized nature of the network.
+Did you know that there are XMPP providers that only open registration during the weekend? Yes, correct.
+Do they now have registration enabled or not? Registration ‘true’ or ‘false’? You tell us…
+There are many more examples on how difficult it can be to find the right and good metric.
+
+Clear is, the rating is not made to blame, but expose user-friendly setups in a simple manner.
+In a simple manner, that we bare exclude setups from reaching a good rating.
+The rating can indicate quality issues, but the main purpose is the recommendation to register especially newcomers to a server or not.
+
+No doubts, ratings are sensitive and they obviously lead to conflict.
+Still, we can proof that we did two strong actions to keep it to a limit and good intentions.
+- Keep the requirements for A as low as possible to ensure a good experience. We believe that even hobby-operators can easily meet these requirements if they want to.
+- Actively reach out and help providers on their setup. And this lead to significant quality improvements in many setups, besides increasing their service rating. Yes, we even sent a postcard to an XMPP service operator and even got a response!
+- We spent extra time and for about six month also host our support chat where we help even beyond the project with technical support with honorable improvements of services.
+- Even more, Melvin did a big effort and wrote our user-friendly, clearly documented and also semi-automated [XMPP Providers Server](https://invent.kde.org/melvo/xmpp-providers-server) setup that anybody can use and start with a good configured setup.
+- After four years we also showed persistence and consistent improvement of quality assurance.
+
+## Vision
+
+The XMPP universe has many chat clients, and many that in one or the other way list and help users to register a new account to an existing or pre-existing list of XMPP server providers.
+This is great and this is what the network nature should be.
+However, the quality of the provided choice of  XMPP server providers varies and has often a manual maintained nature which leads to outdated information and thus, bad experiences.
+Another issues is that on the other side a too restrictive behavior does not support the federated idea.
+That leads to oligopoly-like distribution of users.
+These two extrema of ignorance or mistrust are neither a solution. So let's improve the situation.
+We intend to help to make the onboarding and user experience but also at the same time user decentralization in XMPP great again, at least be an enabler for it.
+An enable through quality and completeness of information and through automation and machine-readability.
+
+We often hear that trust is a big issue. And yes you are right.
+We need control and checks to some extend.
+However, we also need to trust to some extend.
+We claim, that never before there was a more trustworthy open service solutions in the XMPP community than XMPP Providers:
+- a service with that keeps and supports a federated and decentralized interface
+- a service that provides a transparent high level of even semi-automated and up-to-date information of listed servers with soft and hard measures
+- a service tracks and enable quality checks overtime and even help operators with feedback to their service
+- a service provides an API to not just automatically register a new account to a user but also help you as developer and as well the user to for example retrieve service information and support contacts beyond the registration process
+
+Is this a perfect complete response to the difficulties we experience within server, registration and usability? For sure not.
+But it is a strong effort to improve the situation.
+Onboarding in XMPP is a problem since ever and this has barely been tackled across the entire network, and if so with rather isolated solutions.
+It is the unpopular effort we need to do in a decentralized network.
+And even if you think it as a bad solution: It is better than any manually maintained lists we saw before, any unmaintained length lists containing any server you can find and expose themselves in a lottery manner to users to pick from.
+Its better than keeping a purely limited selection of servers in your client that for sure may work, but jeopardizes the idea of federation we all actually like so much.
+
+XMPP Providers, with all the great achievements we have made so far is not the end of the road.
+From a simple list for automatic registration we have evolve to build an API, a website incl. interesting statistics.
+We also think that keeping up with good documentation and transparency is also a great achievement.
+And, instead of talking how to setup you server, we also wrote our own automated setup for everyone to have a good start.
+We encourage you to use XMPP and run your own server instance, maybe even by becoming a public provider.
+Yes, if you want to host your own infrastructure you should do it. 
+But keep in mind that providing a public service comes with great responsibility you should be aware of!
+
+From this point we also believe that the project to some extend evolved from a single purpose to a multi-purpose project.
+We propagate a prerequisite for smooth and sustainable registration process based on up-to-date information and the XMPP users in mind.
+Still, by today this project will likely have more purposes than a good automatic onboarding experience.
+Pick the ones that help your projects and solutions. As said, servers are a key instance in the network, and they have many interfaces.
+There is not the one things to solve and to improve.
+Let’s make the best out of our project, regardless of how you apply to it. We believe it is a great chance.
+
+## Outlook
+
+We plan to expand our API with more measure and more way that you actually can expose the quality of your service, such as up-time and automated ways of confirming existing support.
+But the project is nothing without applications. Gajim will soon publish their implementation of a new registration and on-boarding experience. Stay tuned!
+
+If you got interested to list your service you can start with the provider file and then create an issue here.
+
+Thank you for reading. We invite you to join this endeavor. Reach us in our support chat below.
+
+- The XMPP Providers Team
+
+## Help Us
+
+For a good user experience, [apps integrating XMPP Providers](https://providers.xmpp.net/apps/) are as important as the providers themselves.
+If you are an XMPP developer, please consider [adding XMPP Provider support](https://invent.kde.org/melvo/xmpp-providers#usage) to your app.
+If you are an operator of a public XMPP service, provide the [information we need](/faq/#where-do-we-have-the-providers-properties-from) and [add it to our list](https://invent.kde.org/melvo/xmpp-providers/-/blob/master/CONTRIBUTING.md#providers).
+
+Feel free to [reach out to us](/contact/) if you have any questions!
+
+## Spread the Word
+
+The XMPP Providers project lives from the community.
+We are happy to hear your feedback!
+[Follow us and spread the word](https://fosstodon.org/@xmpp_providers)!
+
+{{< figure src="/images/xmpp-providers-adaptive.svg" caption="XMPP Providers Logo" class="text-center w-100 pt-5" height="300" link="/" >}}
+