home.social

#singlesignon — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #singlesignon, aggregated by home.social.

fetched live
  1. Forcing employees to log in multiple times weakens their willingness to select secure login methods. Consequently, introducing Single Sign-On can go a long way to enhance cybersecurity.

    forbes.com/councils/forbestech

  2. Forcing employees to log in multiple times weakens their willingness to select secure login methods. Consequently, introducing Single Sign-On can go a long way to enhance cybersecurity.
    #cybersecurity #singlesignon
    forbes.com/councils/forbestech

  3. Infinito.Nexus 12.0: From a Single Server to a Scalable Sovereign Cloud

    Infinito.Nexus 12.0 is one of the most significant releases in the project’s history. Until now, Infinito.Nexus focused primarily on automating complete open-source environments on a single Docker Compose host. Version 12.0 introduces Docker Swarm as a second deployment mode, enabling applications to run across multiple servers, scale horizontally and recover from node failures. This release combines capabilities that are rarely delivered by one automation platform: More than 75 automatically deployable open-source applications One Single Sign-On experience backed by a unified user database Horizontal scaling across multiple cloud servers Automated backup and continuously tested disaster recovery Support across Debian, Arch Linux and RHEL-family distributions Filesystem-independent operation across ext4, btrfs and ZFS Together, these changes transform Infinito.Nexus from an application installer into a comprehensive foundation for scalable, sovereign cloud infrastructure. […]

    blog.infinito.nexus/blog/2026/

  4. Look at this! I was finally able to configure all of these apps to allow #SingleSignOn (#SSO) using #kanidm on #NixOS.

    I admit I couldn't do this without the help of an #LLM (I used antigravity-cli for this). I know there are a lot of good points against LLMs, but they sure are really useful to me.

  5. Look at this! I was finally able to configure all of these apps to allow #SingleSignOn (#SSO) using #kanidm on #NixOS.

    I admit I couldn't do this without the help of an #LLM (I used antigravity-cli for this). I know there are a lot of good points against LLMs, but they sure are really useful to me.

  6. Stop Guessing, Start Measuring: The Cold Math of the Passphrase Transition

    1,644 words, 9 minutes read time.

    The Structural Collapse of the Legacy Password

    The traditional eight-character alphanumeric password is a broken line of defense that offers nothing more than a false sense of security. For decades, users have been instructed to construct complex strings filled with uppercase letters, numbers, and obscure symbols, under the mistaken belief that this fragmentation creates an impenetrable barrier. The contemporary threat landscape has rendered these legacy methodologies entirely obsolete, as attackers no longer rely on manual guessing but on automated, high-velocity cryptographic assaults that exploit the inherent predictability of human patterns. To survive in this environment, enterprise architecture must shift toward the passphrase, a credential strategy rooted in length rather than fragmented complexity. This analytical deep dive will demonstrate that information entropy heavily favors length over a constrained character pool, proving that longer strings fundamentally break the mathematical models used by modern cracking tools. Furthermore, an examination of hardware acceleration will reveal how easily graphics processing units dismantle complex but short passwords through sheer processing volume. The analysis will also expose the human failure point, showing how predictable character substitutions actually aid automated dictionary attacks rather than hindering them. Finally, this post will outline the institutional shift led by regulatory frameworks that officially mandates the transition to high-entropy passphrases as a baseline security requirement.

    Why Entropy Defeats Arbitrary Complexity

    The security of any credential rests entirely on its mathematical entropy, which measures the total number of possible combinations an attacker must search through to guarantee a successful breach. Legacy security policies focused intensely on expanding the character pool by forcing users to mix uppercase letters, lowercase letters, numbers, and symbols, assuming this diversity would stall an attack. This logic fails because the total search space scales linearly when adding character types, but scales exponentially when increasing the overall length of the string. An eight-character password drawing from an expanded pool of ninety-four possible characters yields a search space that modern computing clusters can exhaust in a matter of hours. Conversely, a twenty-character passphrase composed exclusively of standard lowercase letters draws from a smaller pool of twenty-six characters, yet its sheer length creates a computational search space that is astronomically larger. The exponential power of length completely dwarfs the linear additions of complexity, making the long string mathematically superior in every measurable metric. Security is a game of resource depletion, and forcing an attacker to calculate permutations across a massive length consumes their time and computational power far more effectively than a short, complex puzzle. Relying on symbols to protect a short credential is a fundamental misunderstanding of cryptographic reality.

    How Modern Computing Power Obliterates Standard Credentials

    The rise of massive hardware acceleration has turned password cracking into an industrialized, automated process that operates at a scale most organizations fail to comprehend. Modern threat actors do not target live login portals where rate-limiting defenses exist; they exfiltrate hashed credential databases and conduct offline attacks using specialized graphics processing unit clusters. A single consumer-grade graphics card can execute billions of cryptographic hash calculations every second, and when multiple cards are parallelized, the throughput becomes devastatingly efficient. Legacy hashing algorithms that were once considered robust offer minimal resistance against this level of raw processing power when the target credential is short. A complex, eight-character password is reduced to a minor computational speed bump when confronted by an array capable of cycling through trillions of permutations in a single afternoon. Passphrases alter this dynamic entirely by forcing the attack automation to scale up its calculations to a point that becomes financially and logistically unviable for the adversary. When a credential possesses sufficient length, the time required to exhaust the mathematical possibilities extends from hours into decades, effectively neutralizing the advantage of hardware acceleration. Organizations that continue to permit short, complex credentials are explicitly ignoring the reality of modern computing capability and leaving their infrastructure vulnerable to rapid automated compromise.

    The Illusion of Security in Character Substitution

    Human psychology is inherently predictable, and when users are forced to create complex strings that defy natural memory retention, they invariably take shortcuts that automated attack tools are specifically designed to exploit. The common practice of replacing a letter with a lookalike number or symbol does not create randomness; it merely creates a predictable pattern that mirrors basic human behavior. Automated dictionary attacks do not guess randomly across the entire character space from the first second; they utilize highly sophisticated rule sets that automatically apply common substitutions to known words. This means an obfuscated password is often broken just as quickly as its plain-text counterpart because the underlying structure remains entirely unoriginal. Furthermore, forcing users to memorize these fragmented, unnatural strings leads directly to credential reuse across multiple platforms, creating a systemic risk where a single third-party breach compromises the entire enterprise. Passphrases solve this fundamental human vulnerability by leveraging words arranged in a sequence that is easy for a human to remember but entirely disjointed to an algorithm. By aligning credential policy with the way the human brain naturally retains information, organizations eliminate the need for dangerous substitutions and drastic reuse, creating a security model that functions in reality rather than only on paper.

    Aligning Enterprise Standards with High-Entropy Passphrases

    The transition from short, complex passwords to long passphrases is no longer a matter of structural debate; it is a formalized directive established by major global cybersecurity frameworks. The National Institute of Standards and Technology explicitly overhauled its digital identity guidelines to eliminate the legacy requirements for arbitrary character complexity and forced periodic expiration. Modern compliance frameworks recognize that frequent password changes and complex character mandates directly degrade security by encouraging predictable patterns and user fatigue. The updated standards heavily prioritize credential length, explicitly advising organizations to configure their identity providers to accept long strings while screening out known compromised entries. Implementing this architecture requires a deliberate reconfiguration of active directory environments, single sign-on platforms, and enterprise identity management systems to support minimum lengths of at least fifteen to twenty characters. Legacy applications that artificially restrict input length must be systematically updated or replaced, as they represent a critical vulnerability that prevents the enforcement of modern entropy standards. Failing to align enterprise architecture with these updated frameworks is a failure of technical oversight that leaves an organization legally and operationally exposed when a breach occurs.

    The Definite Verdict on Credential Architecture

    The data dictates a clear and uncompromising conclusion regarding enterprise credential policy. The legacy framework of short, complex passwords has utterly failed to withstand the realities of modern computing power, automated attack methodologies, and predictable human psychology. Information entropy proves that string length is the primary factor in resisting cryptographic attacks, while hardware acceleration has turned the cracking of short credentials into a trivial task. Human-generated substitutions offer zero protection against sophisticated dictionary rule sets, serving only to complicate user experience while leaving the underlying data vulnerable to exploitation. True security requires a complete rejection of outdated complexity mandates in favor of long, high-entropy passphrases that leverage exponential mathematical growth to exhaust attacker resources. Enterprise infrastructure must adapt immediately to these established standards to mitigate the threat of automated compromise and align with modern regulatory frameworks.

    Enterprise identity architecture must be updated to enforce minimum lengths of fifteen to twenty characters to resist automated exploitation.

    Information entropy mathematically favors credential length over character set complexity, creating exponentially larger search spaces.

    Modern graphics processing unit clusters can rapidly exhaust short, complex credentials through high-velocity offline cracking.

    Predictable human character substitutions fail to deceive modern automated dictionary attacks and encourage dangerous credential reuse.

    Global security frameworks have officially shifted toward prioritizing length and eliminating arbitrary complexity mandates.

    Audit Your Network: Secure Your Enterprise Infrastructure With High-Entropy Passphrases

    Stop relying on an obsolete defense strategy that invites catastrophe. Audit your identity providers immediately, systematically dismantle the arbitrary complexity rules that compromise your user base, and configure your active directory to enforce a strict minimum threshold of fifteen or more characters. The transition to high-entropy passphrases is not an operational preference; it is an immediate cryptographic necessity to shield your enterprise from automated exploitation.

    SUPPORTSUBSCRIBECONTACT ME

    D. Bryan King

    Sources

    Disclaimer:

    The views and opinions expressed in this post are solely those of the author. The information provided is based on personal research, experience, and understanding of the subject matter at the time of writing. Readers should consult relevant experts or authorities for specific guidance related to their unique situations.

    Related Posts

    Rate this:

    #accessControl #accessManagement #accessVulnerability #accountProtection #activeDirectoryConfiguration #authenticationPolicy #automatedCyberAttacks #bruteForceDefense #characterSubstitution #CISAPasswordGuidelines #computerSecurity #credentialReuse #credentialStuffing #cryptographicHash #cyberThreatMitigation #cybersecurityBestPractices #cybersecurityCompliance #dataBreachPrevention #digitalIdentityGuidelines #enterpriseIdentityArchitecture #enterpriseSecurity #GPUPasswordCracking #hardwareAcceleration #highEntropyPassphrase #identityManagement #identityProviders #informationEntropy #ITCompliance #mathematicalEntropy #multiGPUCracking #networkAudit #networkDefense #networkSecurity #NISTSP80063B #offlineDictionaryAttack #passphraseVsPassword #passwordCracking #passwordEntropyFormula #PasswordSecurity #riskMitigation #securityAuditing #securityFrameworks #securityInfrastructure #singleSignOn #stringLength #systemVulnerability
  7. The Double-Edged Sword of Digital Freedom: The Risks of Infinito.Nexus with Native Tor Support

    ⚠️ Disclaimer

    This article was generated entirely by artificial intelligence without editorial review.

    To publish this analysis quickly, I deliberately chose to release it without manual editing or fact-checking. The purpose of this article is not to provide a polished technical specification, but to stimulate discussion about the societal, ethical, and security implications of the next generation of Infinito.Nexus with native Tor support.

    Some technical assumptions, predictions, or conclusions may therefore be incomplete, inaccurate, or open to debate. They should be understood as informed analysis rather than verified fact.

    The scenarios described in this article are intended to illustrate both the opportunities and the risks of increasingly accessible privacy-preserving infrastructure. They do not advocate, encourage, or endorse illegal activity. The same technologies that can strengthen digital sovereignty, protect journalists, human rights organizations, researchers, and political opposition operating under censorship can also be misused by malicious actors.

    The goal of this article is to encourage an open discussion about the consequences of making powerful decentralized infrastructure available to a much broader audience. As with encryption, Linux, Git, peer-to-peer networks, and the Internet itself, technological progress creates both new freedoms and new responsibilities.

    Please read this article critically, verify important claims independently, and view it as a starting point for discussion rather than a definitive statement on the future of decentralized infrastructure.

    Technology is neutral.

    Whether it empowers democratic resistance or enables organized crime depends on the people using it.

    With native Tor integration, Infinito.Nexus has the potential to fundamentally change how self-hosted infrastructure is deployed. It could become possible for anyone to create a completely private digital ecosystem with only minimal technical knowledge.

    That prospect is both exciting — and concerning.

    A World Beyond Traditional Surveillance

    Today’s Internet relies heavily on centralized infrastructure.

    Governments can subpoena cloud providers.

    Internet Service Providers can monitor traffic.

    Hosting companies know where servers are located.

    DNS providers can suspend domains.

    Payment providers can freeze accounts.

    Social media platforms can remove communities.

    Tor changes that equation.

    By integrating Tor directly into the infrastructure layer instead of treating it as an optional add-on, organizations could operate entirely within Onion Services.

    No public IP addresses.

    No public DNS.

    No visible server locations.

    No conventional attack surface.

    Infrastructure that was previously easy to discover suddenly becomes practically invisible to anyone outside the Tor network.

    From Old Smartphones to Invisible Infrastructure

    Perhaps the most disruptive consequence of native Tor support is that almost anyone could become an anonymous infrastructure operator.

    Instead of renting a VPS or purchasing expensive server hardware, users could simply take an old smartphone, install a Linux distribution such as Droidian, deploy Infinito.Nexus, and immediately have a functional server reachable exclusively through Tor.

    Modern smartphones already contain everything traditionally required for a small server:

    • multicore ARM processors
    • flash storage
    • Wi-Fi and LTE connectivity
    • extremely low power consumption
    • integrated batteries acting as an Uninterruptible Power Supply (UPS)

    Unlike conventional servers, smartphones can continue operating during short power outages without requiring any additional hardware.

    Because all communication occurs through Onion Services, the physical location of the device becomes significantly harder to determine than traditionally hosted infrastructure.

    A server could operate from:

    • an apartment
    • an office
    • a vehicle
    • a backpack
    • a cabin
    • virtually anywhere with Internet access

    Instead of racks in a datacenter, entire organizations could operate from inexpensive commodity hardware.

    Infrastructure that once required thousands of dollars could eventually fit inside a jacket pocket.

    Organization Beyond Censorship

    Perhaps the most transformative consequence of native Tor support is not anonymity itself — it is organization.

    Modern democratic movements require far more than encrypted messaging. They need complete digital infrastructure.

    Imagine a group deploying the following services exclusively as Onion Services:

    • Matrix for encrypted communication
    • Nextcloud for document sharing
    • OpenProject for task management
    • Git for software development
    • Wiki systems for documentation
    • forums for public discussion
    • video conferencing
    • identity management with single sign-on

    Every service is accessible only through Tor.

    There are no public IP addresses.

    There are no publicly reachable domains.

    There is no central cloud provider that can simply terminate the infrastructure.

    For political opposition movements operating under authoritarian governments, this could fundamentally change what is possible.

    In countries such as Russia or Iran, governments have repeatedly attempted to restrict independent media, block communication platforms, and pressure hosting providers into taking services offline. A decentralized infrastructure based on Tor Onion Services makes these traditional forms of censorship considerably more difficult.

    If one server disappears, another can be brought online using the same deployment automation and cryptographic identities.

    Instead of relying on a single datacenter, an organization could distribute its infrastructure across many independently operated devices, including repurposed smartphones running Linux distributions such as Droidian. Every device becomes part of the organization’s digital backbone while remaining reachable only through the Tor network.

    This significantly lowers the barrier to building resilient communication networks for journalists, NGOs, researchers, humanitarian organizations, and democratic opposition movements.

    Building Invisible Organizations

    Imagine an organization deploying:

    • Identity Management
    • Matrix
    • Nextcloud
    • Git
    • Email
    • Video Conferencing
    • Project Management
    • Forums
    • Social Networks
    • AI Infrastructure

    Every service exists exclusively as an Onion Service.

    Employees connect only through Tor.

    No public domains.

    No public IP addresses.

    No externally visible services.

    From the perspective of the public Internet, the organization barely exists.

    A Powerful Tool for Democracy

    For many people around the world, this would be an extraordinary step toward digital sovereignty.

    Political opposition operating under authoritarian governments often faces:

    • Internet censorship
    • mass surveillance
    • infrastructure seizures
    • domain confiscation
    • ISP monitoring
    • targeted cyber attacks

    A hidden smartphone consuming only a few watts of electricity could host secure communications for an activist movement.

    Journalists could publish anonymously.

    NGOs could coordinate without relying on commercial cloud providers.

    Entire communities could communicate through infrastructure that is extremely difficult to discover or disable.

    History repeatedly demonstrates that secure communication is one of the foundations of democratic resistance.

    The Other Side of the Coin

    Unfortunately, technology does not distinguish between good and bad actors.

    The exact same infrastructure could also be deployed by:

    • organized cybercrime
    • ransomware groups
    • illegal marketplaces
    • extremist organizations
    • terrorist networks
    • large-scale fraud operations
    • illegal trafficking

    If deploying anonymous infrastructure becomes as simple as flashing Linux onto an old smartphone and clicking through an installation wizard, the barrier to entry changes dramatically.

    What once required experienced Linux administrators could eventually become accessible to almost anyone.

    A hidden smartphone server could host:

    • a secure school collaboration platform

    or

    • an anonymous criminal marketplace.

    Technically, there may be little difference.

    The software cannot distinguish between them.

    Risks for Democratic Societies

    For democratic societies such as Germany, this presents a difficult challenge.

    Security agencies often rely on information obtained from hosting providers, cloud operators, domain registries, DNS providers, or centralized communication platforms during investigations.

    Infrastructure that exists exclusively as Tor Onion Services reduces the availability of these traditional investigative paths.

    This can make investigations more difficult and more resource-intensive, especially when organizations are technically competent and operate their own infrastructure.

    A terrorist cell, extremist group, or organized criminal network could theoretically operate:

    • private Matrix servers
    • encrypted file storage
    • internal forums
    • planning boards
    • identity systems
    • software repositories
    • anonymous web services

    all without relying on public-facing infrastructure.

    That does not mean such groups become impossible to detect.

    Tor does not make people invisible.

    Law enforcement can still use endpoint forensics, undercover operations, financial investigations, human intelligence, surveillance of physical logistics, and mistakes made by suspects.

    But the balance changes.

    The stronger privacy technologies become, the harder traditional bulk surveillance and provider-based investigations become.

    This is exactly why the same tools that protect dissidents in authoritarian states can also create serious challenges for law enforcement in democratic states.

    The Democratization of Anonymous Infrastructure

    Historically, operating Onion Services required substantial expertise.

    Administrators needed to understand:

    • Linux
    • networking
    • reverse proxies
    • DNS
    • Tor
    • certificates
    • firewalls
    • application integration

    Automation changes everything.

    Eventually, the entire deployment process could become:

    1. Install Droidian on an old smartphone.
    2. Install Infinito.Nexus.
    3. Select the desired applications.
    4. Enable Tor support.
    5. Click Deploy.

    Minutes later, an entire private infrastructure could be online.

    No cloud provider.

    No VPS.

    No static IP.

    No public DNS.

    Infrastructure that previously required experienced system administrators becomes accessible to ordinary users.

    That democratization is both empowering and dangerous.

    Open Source Has Always Faced This Dilemma

    This is not a new ethical problem.

    Encryption protects:

    • journalists
    • dissidents
    • criminals

    VPNs protect:

    • activists
    • ransomware operators

    Git is used to build:

    • medical software
    • malware

    Linux powers:

    • hospitals
    • botnets

    Artificial Intelligence can:

    • accelerate scientific discovery
    • generate phishing campaigns

    Technology itself has no morality.

    People do.

    Infinito.Nexus Is Infrastructure

    Infinito.Nexus is not being developed to create hidden criminal networks.

    Its purpose is to simplify the deployment of sovereign, self-hosted infrastructure.

    Native Tor support simply extends that philosophy.

    The software itself does not decide who uses it.

    The responsibility remains with those who deploy it.

    The Ethical Challenge

    Should powerful privacy technologies be withheld because they could be abused?

    Or should society accept that technologies capable of protecting freedom will inevitably also be exploited by malicious actors?

    There is no perfect answer.

    Throughout history, almost every revolutionary communication technology — from the printing press to encrypted messaging — has been used for both constructive and destructive purposes.

    Tor is no different.

    Neither is Infinito.Nexus.

    Technical Design

    Native Tor support is currently being designed as a core networking feature of Infinito.Nexus.

    Instead of treating Tor as an optional add-on, every deployed application can automatically receive its own Onion Service while remaining fully integrated into the deployment framework.

    The current design proposal is publicly available:

    Native Tor Support Requirements
    https://github.com/kevinveenbirkenbach/infinito-nexus-core/blob/feature/svc-net-tor/docs/requirements/031-svc-net-tor-onion.md

    Related projects:

    Infinito.Nexus Core
    https://github.com/kevinveenbirkenbach/infinito-nexus-core

    Hetzner Arch LUKS
    https://github.com/kevinveenbirkenbach/hetzner-arch-luks

    Linux Image Manager
    https://github.com/kevinveenbirkenbach/linux-image-manager

    These projects together lay the groundwork for a future where deploying fully encrypted, self-hosted, Tor-native infrastructure becomes almost as simple as installing a mobile app.

    Conclusion

    Native Tor support has the potential to fundamentally reshape how self-hosted infrastructure is deployed.

    For the first time, individuals, NGOs, journalists, companies, and political opposition movements could build private digital ecosystems with remarkably little technical expertise.

    At the same time, the same technology could lower the barrier for anonymous criminal infrastructure.

    A discarded smartphone running Linux could become a resilient, battery-backed server hidden almost anywhere.

    That reality is both inspiring and unsettling.

    Like encryption, Linux, Git, VPNs, and the Internet itself, Infinito.Nexus is infrastructure.

    Infrastructure does not decide how it is used.

    People do.

    The challenge for society is therefore not whether such technology should exist, but how we choose to live in a world where powerful privacy tools become accessible to everyone.

    #Activism #AnonymousCommunication #AnonymousHosting #AnonymousInfrastructure #AnonymousServers #CensorshipResistance #CircumventingCensorship #Cybersecurity #Decentralization #DecentralizedInfrastructure #DevOps #DigitalRights #DigitalSovereignty #Droidian #EndToEndEncryption #FreedomOfSpeech #FullDiskEncryption #git #HumanRights #IdentityManagement #InfinitoNexus #InformationSecurity #InfrastructureAsCode #infrastructureAutomation #InternetCensorship #Iran #Journalism #Linux #LinuxServer #LUKS #Matrix #MatrixServer #MobileServer #NetworkSecurity #Nextcloud #NGOs #OnionServices #OpenSource #OpenProject #Privacy #PrivacyTechnology #RemoteUnlock #Russia #SecureCommunication #SecureInfrastructure #SelfHosting #SelfSovereignInfrastructure #SelfHostedInfrastructure #ServerHardening #SingleSignOn #SmartphoneServer #SSHOverTor #Tor #TorHiddenServices #TorHosting #TorNetwork
  8. WHERE OTHERS LOSE CONTROL – WE STAY IN THE LOOP.

    At Infinito.Nexus, we believe that AI should never replace human judgment. We are the captains. AI is our navigator. While others hand over responsibility to black-box systems, we stay in control. We design the architecture, review the code, verify every deployment, and make the decisions that shape the future of the systems we build. AI is one of the most powerful tools ever created. But it remains a tool. We are the engineers, architects, and craftsmen who use it to build sovereign digital infrastructure faster, more reliably, and at a scale that was impossible only a few years ago. […]

    blog.infinito.nexus/blog/2026/

  9. I need to vent.

    I don’t want to know how much time I spend singing in / logging in to some software. The employee side is just annoying - they use a #singleSignOn app, but I have to confirm multiple times every day. At least it is all accessible without removing the phone from the dock. But my customer resets their virtual desktops every night and has turned off #SSO.

  10. Digitale Souveränität jetzt sichern

    Digitale Souveränität ist längst keine theoretische Debatte mehr, sondern eine strategische Notwendigkeit. Was sich aktuell abzeichnet, ist nicht nur ein technologischer Wandel, sondern eine geopolitische Verschiebung, die direkten Einfluss auf europäische Unternehmen hat. Die Diskussion in der Schweiz über ein faktisches Cloud-Verbot für sensible Daten zeigt, wie ernst die Lage inzwischen eingeschätzt wird. Gleichzeitig geraten große Anbieter wie Microsoft zunehmend unter Druck durch wettbewerbsrechtliche Prüfungen. Sicherheitsvorfälle wie das Datenleck im Schweizer Außendepartement verdeutlichen zusätzlich, wie verwundbar zentrale Systeme sind. Auch politisch verschärft sich die Lage. Frankreich denkt offen darüber nach, sich von US-Technologien wie Windows zu lösen. Der Hintergrund ist klar. Digitale Infrastruktur ist längst Teil geopolitischer Macht. […]

    blog.infinito.nexus/blog/2026/

  11. Digitale Souveränität jetzt sichern

    Digitale Souveränität ist längst keine theoretische Debatte mehr, sondern eine strategische Notwendigkeit. Was sich aktuell abzeichnet, ist nicht nur ein technologischer Wandel, sondern eine geopolitische Verschiebung, die direkten Einfluss auf europäische Unternehmen hat. Die Diskussion in der Schweiz über ein faktisches Cloud-Verbot für sensible Daten zeigt, wie ernst die Lage inzwischen eingeschätzt wird. Gleichzeitig geraten große Anbieter wie Microsoft zunehmend unter Druck durch wettbewerbsrechtliche Prüfungen. Sicherheitsvorfälle wie das Datenleck im Schweizer Außendepartement verdeutlichen zusätzlich, wie verwundbar zentrale Systeme sind. Auch politisch verschärft sich die Lage. Frankreich denkt offen darüber nach, sich von US-Technologien wie Windows zu lösen. Der Hintergrund ist klar. Digitale Infrastruktur ist längst Teil geopolitischer Macht. […]

    blog.infinito.nexus/blog/2026/

  12. Dag 3 i resan mot digital självständighet: Dags att gallra bland kontona

    Digital självständighet: Kartläggning och strategier för att hantera online-konton Under dag 3 i resan mot digital självständighet rekommenderar The Opt Out Project att du börjar med att kartlägga alla dina online-konton. Ett effektivt sätt att starta är att granska din lösenordshanterare, såsom KeePassXC, Bitwarden eller LastPass. Genom att organisera kontona i kategorier som Avveckla, SSO (Single Sign-On), Nödvändiga, Migrera, Stanna och Radera genast kan du skapa en tydlig överblick över vilka konton som behöver åtgärdas. Strategier för digital självständighet The Opt Out Project föreslår flera strategier för att uppnå digital självständighet: - Välj tjänster med omsorg: Använd tjänster du litar på eller hosta dem själv, till exempel genom samarbete med föreningar som Kamratdataföreningen Konstellationen. - Data-balkanisering: Utnyttja konkurrensen mellan techjättar genom att använda tjänster från olika företag för att minska risken för datadelning. - Använd tjänster för specifika ändamål: Begränsa användningen av tjänster som Google Maps eller LinkedIn till deras huvudsakliga funktioner. Praktisk tillämpning Med över 450 konton i en lösenordshanterare kan processen kännas överväldigande. Genom att använda en kalkylmallsmodell i LibreOffice Calc kan du effektivt sortera och kategorisera dina konton. Exempel på kategorisering: - Radera genast: Konton som Civilization 6 eller Fobizz, som inte längre används. - Migrera: Konton som Hue eller Rakuten Kobo, där du kan byta inloggningsmetod. - Stanna: Tjänster som respekterar din integritet och har säkra inloggningar. Resultat och reflektioner Efter kartläggningen kan du identifiera vilka konton som ska raderas (116), migreras (33), behållas (37) eller är nödvändiga (13). Använd verktyg som Proton Mail för att skapa alias och öka säkerheten.

    godaliv.se/digital-suveranitet

  13. Infinito.Nexus vs. YunoHost

    Similar Vision, Different Architectural Layer When people first hear about Infinito.Nexus, a common question is: “Isn’t this basically like YunoHost?” It’s a fair question. Both projects support digital sovereignty.Both are open source.Both aim to reduce dependency on Big Tech platforms. But they operate at fundamentally different architectural layers. YunoHost → https://yunohost.org Infinito.Nexus → https://infinito.nexus The Core Difference The most important distinction: Infinito.Nexus is not an operating system. YunoHost behaves like a server distribution — a tightly integrated system environment that packages applications into a controlled OS base. Infinito.Nexus, by contrast, is a provisioning and orchestration framework. It does not replace the operating system.It provisions and orchestrates infrastructure on top of it. This architectural choice makes Infinito.Nexus significantly more scalable and flexible. Instead of being tied to a specific system base, it operates across environments — allowing infrastructure to grow without requiring replatforming. […]

    blog.infinito.nexus/blog/2026/

  14. Infinito.Nexus vs. YunoHost

    Similar Vision, Different Architectural Layer When people first hear about Infinito.Nexus, a common question is: “Isn’t this basically like YunoHost?” It’s a fair question. Both projects support digital sovereignty.Both are open source.Both aim to reduce dependency on Big Tech platforms. But they operate at fundamentally different architectural layers. YunoHost → https://yunohost.org Infinito.Nexus → https://infinito.nexus The Core Difference The most important distinction: Infinito.Nexus is not an operating system. YunoHost behaves like a server distribution — a tightly integrated system environment that packages applications into a controlled OS base. Infinito.Nexus, by contrast, is a provisioning and orchestration framework. It does not replace the operating system.It provisions and orchestrates infrastructure on top of it. This architectural choice makes Infinito.Nexus significantly more scalable and flexible. Instead of being tied to a specific system base, it operates across environments — allowing infrastructure to grow without requiring replatforming. […]

    blog.infinito.nexus/blog/2026/

  15. Guten Morgen, ich hoffe, Eure Anreise nach Bremen zum #univentionsummit wird nicht zu abenteuerlich bei dem Wetter!

    Hier ein kleine Reiselektüre für die, die schon mal spicken möchten, was diese Authentication Flows sind, über die ich morgen spreche:

    keycloak.org/docs/latest/serve

    #keycloak #sso #singlesignon #freesoftware @univention

  16. Guten Morgen, ich hoffe, Eure Anreise nach Bremen zum #univentionsummit wird nicht zu abenteuerlich bei dem Wetter!

    Hier ein kleine Reiselektüre für die, die schon mal spicken möchten, was diese Authentication Flows sind, über die ich morgen spreche:

    keycloak.org/docs/latest/serve

    #keycloak #sso #singlesignon #freesoftware @univention

  17. 💪 Ready to simplify DNS access for your organization? Managing DNS access across multiple domains and teams can get messy. This video shows how to use Microsoft Entra SSO with DNSimple so your team sign in once & gets the right level of access.
    👉 Watch youtu.be/hpBNoXc2reU

    #MicrosoftEntra #EntraID #EntraSSO #SingleSignOn #SSO #Security #DNS

  18. 💪 Ready to simplify DNS access for your organization? Managing DNS access across multiple domains and teams can get messy. This video shows how to use Microsoft Entra SSO with DNSimple so your team sign in once & gets the right level of access.
    👉 Watch youtu.be/hpBNoXc2reU

    #MicrosoftEntra #EntraID #EntraSSO #SingleSignOn #SSO #Security #DNS

  19. If you contribute to @wikipedia @wikidata #WikimediaCommons #Wikivoyage, you can join OpenHistoricalMap in just a few clicks, without having to juggle yet another password for yet another wiki. It works a lot like our existing OpenStreetMap login support.

    #SingleSignOn #OAuth2

  20. If you contribute to @wikipedia @wikidata #WikimediaCommons #Wikivoyage, you can join OpenHistoricalMap in just a few clicks, without having to juggle yet another password for yet another wiki. It works a lot like our existing OpenStreetMap login support.

    #SingleSignOn #OAuth2

  21. Allmählich kehrt im Büro Ruhe ein. 🎅🏻 Hier bin ich bei meinen Vortragsvorbereitungen für den Univention-Summit: "Authentication Flows in Keycloak". Seid Ihr dabei? 28./29.1. in Bremen.

    #singlesignon #keycloak #univentionsummit #bremen #freesoftware #opensource

  22. Allmählich kehrt im Büro Ruhe ein. 🎅🏻 Hier bin ich bei meinen Vortragsvorbereitungen für den Univention-Summit: "Authentication Flows in Keycloak". Seid Ihr dabei? 28./29.1. in Bremen.

    #singlesignon #keycloak #univentionsummit #bremen #freesoftware #opensource

  23. Ein Stack, der zusammenarbeitet: Warum Infinito.Nexus mehr ist als SaaS

    In der heutigen IT-Landschaft bieten nahezu alle großen Hoster eine Vielzahl an Tools und Diensten an: von Web-Apps über Datenbanken bis hin zu kompletten Entwicklungsumgebungen. Auf den ersten Blick scheint es, als könne man mit ein paar Klicks alles selbst zusammenstellen. Doch wer versucht hat, diese einzelnen Komponenten sicher, integriert und wartbar zu verbinden, weiß: Das ist leichter gesagt als getan. […]

    blog.infinito.nexus/blog/2025/

  24. Moin! Dieses Jahr biete ich die ganztägige Keycloak-Schulung noch 1x an, am 18. November. Ein Platz ist noch frei. Die Zielgruppe sind Admin*s, die den von @univention ausgelieferten Keycloak in Verbindung mit UCS einsetzen. SSO-Vorkenntnisse sind nicht nötig. Hier sind die Details zur Anmeldung:

    univention.de/training/keycloa

    #keycloak #singlesignon #oidc #saml #univention

  25. Moin! Dieses Jahr biete ich die ganztägige Keycloak-Schulung noch 1x an, am 18. November. Ein Platz ist noch frei. Die Zielgruppe sind Admin*s, die den von @univention ausgelieferten Keycloak in Verbindung mit UCS einsetzen. SSO-Vorkenntnisse sind nicht nötig. Hier sind die Details zur Anmeldung:

    univention.de/training/keycloa

    #keycloak #singlesignon #oidc #saml #univention

  26. Ich habe das Gefühl, dass ich mich mit #SingleSignOn öfter anmelden muss als ohne.

    #SSO

  27. Ich habe das Gefühl, dass ich mich mit #SingleSignOn öfter anmelden muss als ohne.

    #SSO

  28. Infinito.Nexus: Die Zukunft von SSO & IAM für Unternehmen und Communities

    Die digitale Welt wird immer komplexer. Unternehmen, Organisationen und Communities nutzen heute eine Vielzahl an Anwendungen – von Projektmanagement-Tools über Cloud-Speicher bis hin zu sozialen Plattformen. Damit steigt die Herausforderung, Identitäten, Rechte und Zugriffe effizient, sicher und benutzerfreundlich zu verwalten. Genau hier setzt Infinito.Nexus an: mit einer einzigartigen Kombination aus Single Sign-On (SSO) und Identity & Access Management (IAM), die weit über klassische Enterprise-Lösungen hinausgeht. […]

    blog.infinito.nexus/blog/2025/

  29. Infinito.Nexus: Der komplette Entwicklungs-Stack in unter zwei Stunden

    Softwareentwicklungsfirmen stehen oft vor der Herausforderung, zahlreiche Systeme zur Zusammenarbeit, Versionsverwaltung, Kommunikation, Dokumentation und Sicherheit aufzusetzen. Infinito.Nexus löst dieses Problem in weniger als zwei Stunden – modular, automatisiert und vollständig integriert. […]

    blog.infinito.nexus/blog/2025/

  30. Infinito.Nexus: Der komplette Entwicklungs-Stack in unter zwei Stunden

    Softwareentwicklungsfirmen stehen oft vor der Herausforderung, zahlreiche Systeme zur Zusammenarbeit, Versionsverwaltung, Kommunikation, Dokumentation und Sicherheit aufzusetzen. Infinito.Nexus löst dieses Problem in weniger als zwei Stunden – modular, automatisiert und vollständig integriert. […]

    blog.infinito.nexus/blog/2025/

  31. Wissensmanagement im Nexus: MediaWiki, Discourse & Confluence out of the Box

    In modernen Organisationen ist Wissen die entscheidende Ressource. Ob als kollaboratives Nachschlagewerk, als strukturierte Projektdokumentation oder als lebendige Community-Diskussion: ohne ein gut eingebundenes Wiki- oder Wissenssystem verlieren Teams wertvolle Zeit.Das Infinito.Nexus stellt deshalb drei etablierte Systeme out of the box bereit: MediaWiki, Discourse und Confluence. Alle drei sind nahtlos über LDAP und OpenID Connect (OIDC) in den eigenen Mikrokosmos eingebunden – entweder über das vom Nexus bereitgestellte OpenLDAP oder über eine direkte Active-Directory-Integration, falls bereits eine Microsoft-Infrastruktur vorhanden ist. Damit wird Infinito.Nexus zu einer echten Alternative zu Microsoft SharePoint: leistungsfähig, flexibel, anpassbar und voll OnPremise kontrollierbar. […]

    blog.infinito.nexus/blog/2025/

  32. Der Nexus – Ein Internet, das wieder uns gehört

    Das Internet ist zu einem Ort geworden, an dem wir oft abhängig sind: von Facebook, von YouTube, von LinkedIn, von zentralen Plattformen, die unsere Daten kontrollieren, unsere Kommunikation steuern und uns mit Werbung überfluten. Wir leben in einer Zeit, in der wir ausspioniert werden, unsere Daten teuer verkauft werden und wir durch Marketing-Algorithmen und Manipulation in unserem Denken und Handeln beeinflusst werden. Wir sind nicht mehr die Nutzer des Internets – wir sind die Ware. Doch so war das Internet nicht gedacht. Es sollte frei sein, dezentral, ein Ort, an dem Gemeinschaften wachsen können. Genau hier setzt Infinito.Nexus an: Es baut auf den guten Ideen des frühen Internets auf – mit allen technischen Möglichkeiten, die wir heute haben. […]

    blog.infinito.nexus/blog/2025/

  33. Der Nexus – Ein Internet, das wieder uns gehört

    Das Internet ist zu einem Ort geworden, an dem wir oft abhängig sind: von Facebook, von YouTube, von LinkedIn, von zentralen Plattformen, die unsere Daten kontrollieren, unsere Kommunikation steuern und uns mit Werbung überfluten. Wir leben in einer Zeit, in der wir ausspioniert werden, unsere Daten teuer verkauft werden und wir durch Marketing-Algorithmen und Manipulation in unserem Denken und Handeln beeinflusst werden. Wir sind nicht mehr die Nutzer des Internets – wir sind die Ware. Doch so war das Internet nicht gedacht. Es sollte frei sein, dezentral, ein Ort, an dem Gemeinschaften wachsen können. Genau hier setzt Infinito.Nexus an: Es baut auf den guten Ideen des frühen Internets auf – mit allen technischen Möglichkeiten, die wir heute haben. […]

    blog.infinito.nexus/blog/2025/

  34. Infinito.Nexus – Eine Plattform für digitale Souveränität und vernetzte Zusammenarbeit

    Die digitale Transformation stellt heute alle gesellschaftlichen Bereiche vor enorme Herausforderungen. Öffentliche Verwaltungen kämpfen mit komplexen IT-Landschaften, Bildungsträger suchen nach sicheren und offenen Lernumgebungen, und Unternehmen benötigen flexible Plattformen für Kollaboration und Innovation. Währenddessen wächst der Druck, digitale Souveränität zu stärken und sich nicht von wenigen globalen Konzernen abhängig zu machen. Genau hier setzt Infinito.Nexus an: ein Open-Source-Framework, das komplette digitale Infrastrukturen automatisiert bereitstellt und eine Vielzahl erprobter Anwendungen nahtlos miteinander verbindet. […]

    blog.infinito.nexus/blog/2025/

  35. Die Woche wird total spannend! Ich bin am Donnerstag in Amsterdam auf der Keycloak-Konferenz KeyConf25. Treffe ich dort jemanden von Euch? keyconf.dev/

    #Keycloak #SSO #singlesignon #freesoftware #floss #keyconf

  36. Die Woche wird total spannend! Ich bin am Donnerstag in Amsterdam auf der Keycloak-Konferenz KeyConf25. Treffe ich dort jemanden von Euch? keyconf.dev/

    #Keycloak #SSO #singlesignon #freesoftware #floss #keyconf

  37. Für "Identity Broker"-Szenarien mit Keycloak finde ich die Doku von Red Hat empfehlenswert. Dort ist verhältnismäßig gut beschrieben, wie man das Durchreichen von Claims/Attributen von einem Identity Provider durch einen anderen zu einem Client konfiguriert.

    docs.redhat.com/en/documentati

    #keycloak #singlesignon #iam #oidc #saml

  38. Für "Identity Broker"-Szenarien mit Keycloak finde ich die Doku von Red Hat empfehlenswert. Dort ist verhältnismäßig gut beschrieben, wie man das Durchreichen von Claims/Attributen von einem Identity Provider durch einen anderen zu einem Client konfiguriert.

    docs.redhat.com/en/documentati

    #keycloak #singlesignon #iam #oidc #saml

  39. CyMaIS: Nahtlose LDAP-AD-Kompatibilität via Keycloak für Ihre hybride Open-Source-Infrastruktur

    In vielen Unternehmen koexistieren proprietäre Microsoft-Umgebungen und der Wunsch nach offenen, lizenzfreien Lösungen. CyMaIS schließt diese Lücke durch eine vollständige LDAP-AD-Kompatibilität: Bestehende Active-Directory-Infrastrukturen bleiben intakt, während Open-Source-Dienste nahtlos angebunden werden können. Mit der Integration von Keycloak als Identity-Provider (IdP) bietet CyMaIS zudem echtes Kerberos-SSO über LDAP, ohne selbst GSSAPI-Bindings implementieren zu müssen.

    […]

    blog.cymais.cloud/blog/2025/06

  40. @Strypey Locally writing content to the database of an ActivityPub-based server will inevitably require a local user account on that very server.

    I mean, we already have OpenWebAuth magic sign-on which was invented by @Mike Macgirvin ?️ for Hubzilla in 2017, and which also has full implementations in his later server applications (streams) and Forte and a client-side implementation on Mike's first project, Friendica. But without an actual account on another server, OpenWebAuth can only authenticate you on that other server as a guest and grant you certain guest permissions. It does not give you all the powers of a local user, at least not without a local account.

    Also, if you want to actually log in on another server, you will inevitably need local login credentials on that server. Which means that a user account with these login credentials must be created prior to you logging in on that server so that that server knows your login name and your password. Even if you want to use something like OAuth, that server will still require to know your credentials. They will have to be in that server's database before you can successfully log in.

    A server cannot and will not authenticate you against credentials in a wholly different remote server's database. What you and many other Fediverse users dream of can only be solved in two ways and both only theoretically because, in practice, they are just as impossible or at least very unfeasible.

    Either if you register an account on one Fediverse server, that account with the exact same credentials is simultaneously created on literally all other Fediverse servers, and on Hubzilla, (streams) and Forte, you also automatically get a channel along with that account. This also means that each Fediverse server that's installed and spun up for the first time will immediately have to create tens of millions of accounts so that everyone all over the Fediverse automatically has login credentials on that server. I guess it should be clear that this is impossible, also because this requires a) a centralised list of absolutely all Fediverse accounts and identities and b) a centralised list of all Fediverse servers to be hard-coded into every last instance of every last Fediverse server out there.

    Now, I keep reading stuff like, "But I don't want to use all Fediverse servers!" No, but you want to be able to use any Fediverse server. And then you will have to have an account there. How is the Fediverse supposed to know in advance which servers you will visit this year, the next two years, five years, ten years so that accounts can be automatically created for you exactly there and nowhere else?

    See? And that's why, if you want to be able to use any server like with a local account, every server must be prepared for it before you arrive.

    Or drive-by registration: You visit a Fediverse server for the first time, your active login is recognised by that Fediverse server, and an account is created for you on the fly with the exact same login credentials as where you're already logged in. That's its own can of worms.

    Also, it requires remote authentication. OpenWebAuth. As I've already said: This is technology that's eight years old, and that's being daily-driven right now. But: You will never have this on Mastodon. There actually is a pull request for Mastodon from two years ago that would have implemented client-side OpenWebAuth support. It was never merged. It was silently rejected by the Mastodon developers. The PR was closed in November, 2024.

    Some people go even further: They don't just want their login credentials wherever they go, they want their whole identity cloned to everywhere. They want all their stuff, all their posts and comments and DMs, all their followers and followed, all their settings, all their filters etc. etc. pp., they want it everywhere all the same. Like a nomadic identity (an invention by Mike from 2011, first implemented in 2012) across up to 30,000 servers.

    Now, you and many others on Mastodon are probably going to cry out, "YES, YES, PLEASE MAKE THIS REALITY!"

    But seriously: I myself have actually cloned enough Hubzilla and (streams) channels of mine in my time. None of them even had nearly as much content on them as your Mastodon account. And I can tell from a lot of personal experience that this cannot be done within a blink of an eye.

    Nomadic identity won't come to Mastodon anyway. Nomadic identity via ActivityPub is probably being daily-driven already. Forte has it, and it relies on it. But Mastodon will never implement it. In particular, Mastodon would rather re-invent the "nomadic identity" wheel in a way that's incompatible with what we already have than implement something made by Mike Macgirvin. Not after all the head-butting that has happened between Mike and Gargron over the years.

    And OpenWebAuth won't come to Mastodon either. Probably also for the same reason.

    CC: @Tim Chambers @rakoo @Ben Pate 🤘🏻

    #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity
  41. Von #SingleSignOn Systemen bin ich noch nie ein Freund gewesen: Einmal gehackt, stehen einem sämtliche damit verbundene Accounts offen. Jeder Service verdient seine eigenen Zugangsdaten. Thanks god for password managers :mastowink:

    «In the darkness bind them»: Intransparenz bei OneLog - Das Netz ist politisch
    - von @adfichter & @marcel

    dnip.ch/2024/11/05/onelog-dark #Journalismus #journalism #Datenschutz #privacy #DataLeak #Datenleck #OneLog #Zensur #censorship

  42. @Ben Pate 🤘🏻 Allow me to take a look at this from a Hubzilla/(streams)/Forte point of view.

    The Sin of Overwhelming Complexity: Instance Selection Paralysis


    The only way to really combat this effectively is by hiding the whole concept of servers/instances at first, railroading everyone to a server and only letting them know about decentralisation and servers/instances after the fact.

    In theory, this could be doable with Hubzilla, (streams) and Forte, and even better than with Mastodon with its themed servers. It wouldn't make sense to offer Hubzilla, (streams) or Forte servers for certain topics or target audiences, seeing as the whole thing would become moot the very moment when you make your first clone on another server. Simply build a kind of "automatic on-boarder" that sends everyone to the geographically closest open-registration server.

    In practice, that'd be a bad idea, but for a different reason than on Mastodon. And that's how these servers tend to be very different. Not in topic. Not in target audiences. Not in rules. But in features. Hubzilla is modular, (streams) is modular, Forte is modular, and each admin decides differently on which "apps" to activate. Then you want to join Hubzilla for one cool feature, but the on-boarder railroads you to a server where that very feature isn't even activated.

    Sure, the on-boarder could include the option to select certain features that you absolutely must have in your new home and then pick a server that has them. But that'd be extra hassle and extra confusing.

    Besides, where'd you put that on-boarder? On the official Hubzilla website? Haha, no can do. The official Hubzilla website is a webpage on a Hubzilla channel itself. It's all just dumb old static HTML with a CSS. If it's even HTML and not Markdown or BBcode, that is. You couldn't add scripts to it if you tried.

    Oh, and (streams) and Forte don't even have official websites. And (streams) will never have one, seeing as it's officially and intentionally nameless, brandless and totally not even a project. Their "websites" are readme files in their code repositories on Codeberg.

    The Sin of Inconsistent Navigation: Timeline Turmoil


    The streams on Hubzilla, (streams) and Forte are quite a bit different from Mastodon timelines.

    First of all, what you usually don't have on public servers is the counterpart to Mastodon's local timeline and Mastodon's federated timeline. On all three, this would be only one stream, the "public stream" or "pubstream". It can be switched by the admin to either what'd be local or what'd be federated. However, public servers usually have it off entirely. Unavailable even to local users. That's because the admins don't want to be held liable for what's happening on the pubstream.

    Technically speaking, you only have one stream on a public server, and that's your channel stream. It's much more efficient than a Mastodon timeline because it always shows entire conversations by default instead of detached single-message piecemeal, and because it has a counter for unread messages which even lists these unread messages for you to directly go to the corresponding conversation. But that's another story.

    However, your channel stream can be viewed on your channel page, conversation by conversation, or it can be viewed on the stream page as an actual stream with all conversations shown in a feed/timeline-like fashion, one upon another, and with its own set of built-in filters such as "only my own messages" or "only conversations started by members of one particular privacy group/access list" or "only conversations from one particular group actor". It's actually much more convenient than any Mastodon timeline, but for those who want a Twitter clone for dumb-dumbs, it can be very overwhelming.

    Yes, Hubzilla, (streams) and Forte are much more complex in handling than, say, snac2. But they're also much more complex in features than snac2. That power is their USP. And that power must be harnessed somehow.

    The Sin of Remote Interaction Purgatory: Federation Gymnastics


    Sure, Hubzilla, (streams) and Forte have some of the best built-in search systems in the whole Fediverse. They can pull almost everything onto your channel stream just by searching for it. And if it has replies, chances are they pull these in as well.

    But still, they're geared towards desktop users. They still require copy-paste. Phone users don't copy paste. Most of them don't even know the very concept of copy-paste. For most of those who do, copy-paste is much too fumbly if the input device available to them is a 6" touch screen.

    You can't blame them, though. This is next to impossible to do any differently. I mean, you won't see a button magically appear with which you can pull in just that one post or comment you want to pull in.

    Rather, the issue is that they can only reel in almost everything. Sometimes the search returns nothing, like a void. Sometimes the search runs indefinitely without any kind of result. This may be because someone has blocked your channel, because someone has blocked your entire server, because the server someone is on has blocked you or your entire server, because Hubzilla/(streams)/Forte doesn't understand the URI pasted into the search field or whatever.

    So this is made worse by Hubzilla, (streams) and Forte not knowing what they can search for, what they can't and why not.

    Connecting with someone whom you encounter on your channel stream is fairly easy. Connections can be initiated with only two clicks. Either you click their long name, and you're taken to a pretty much distraction-less local "intermediate page" with a striking green button that's labelled "+ Connect". Or if you don't want to leave the channel page, you hover your mouse cursor over their profile picture, click on the little white arrow that appears, and you get a small menu that offers you the "Connect" option as well. Granted, even some veterans don't know the latter trick because it isn't immediately advertised on the channel page.

    Also, sure, you don't simply follow them right off the bat with nothing else to do like on Mastodon. You're taken to your Connections page, and you have to configure the connection (you don't have to do that on Mastodon because you can't configure connections on Mastodon).

    Following accounts/channels from the directory is a bit easier. The green "+ Connect" button is there right away (unless you're already connected). However, Hubzilla's directory only lists channels based on the Nomad protocol, i.e. Hubzilla and (streams) channels, because ActivityPub is only implemented in an optional, off-by-default-for-new-channels add-on whereas it's in the core and on by default on (streams) and the only available protocol on Forte.

    Importing contents or following actors when seeing them locally on other servers without copy-pasting and searching can be done. It requires OpenWebAuth magic single sign-on, however, and it requires it to be implemented on all servers of all Fediverse server applications from Mastodon to WordPress to Ghost to Flipboard. Hubzilla, (streams) and Forte are the only Fediverse server applications with full (client-side and server-side) OpenWebAuth implementations. But that's of little use if the rest of the Fediverse doesn't have server-side implementations, and Mastodon has even silently rejected a mere client-side implementation already developed to a pull request two years ago.

    The Sin of DM Disasters Waiting to Happen


    I think this is less of an issue on Hubzilla, (streams) and Forte because they handle DMs differently from Mastodon (which "the Fediverse" actually refers to in the article).

    On all three, DMs are integrated into their extensive, fine-grained permissions system in which everything is only public if it's really public. The difference between a post and a DM is not just a switch.

    If I want to DM you, I can either tag you @!{[email protected]} rather than @[url=https://mastodon.social/@benpate]Ben Pate 🤘🏻[/url]. Then you're a) the only one to whom the message is sent (it literally doesn't even go out to any other server than mastodon.social plus my clone on hub.hubzilla.de as can be seen in the delivery report) and b) the only one who is granted permission to view the message.

    Or I can use the padlock icon and select you from the opening list as the sole recipient. The very moment that I select certain recipients, the post I'm composing quits being public, and the padlock icon switches from open to closed. This isn't a one-click or two-click toggle. You don't do that casually. It's basically configuration. It requires so many mouse clicks that you do it consciously and intentionally. If you want to post in private, you have to really want to post in private.

    Better yet: You can default to posting only to a certain limited target audience. In fact, by default on a brand-new channel, you only post to the members of one privacy group/access list (which is a Mastodon list on coke and 'roids). You have to manually reconfigure your new channel if you want to post to the general public by default.

    If you preview your post, you can see whether it's a direct message to one or multiple single connections (envelope icon next to your long name), a limited-permissions message to one or multiple privacy groups/access lists/group actors (closed padlock icon) or actually public (no icon).

    Even better yet: Posts to group actors generally aren't public. Posts to at least Friendica groups, Hubzilla forums, (streams) groups and Forte groups are never public. They do not go out to your followers as well unless they're connected to the same group. And this is independent from whether a group is public or private. You can't accidentially post to a group actor in public, and if you do, you don't post to that group actor at all, at least not in a way that makes the group actor forward your post to its other connections.

    Granted, what does not happen is your background switching from your background colour or background image (which can be user-configured) to red #800000 or a yellow-and-back chevron pattern when you change visibility and permissions to something that isn't public.

    The Sin of Ghost Conversations and Phantom Follower Counts


    And again, when @Tim Chambers says, "the Fediverse", he almost exclusively means Mastodon. He writes as if the entire Fediverse handled conversations as terribly as Mastodon, as if the entire Fediverse was as blissfully unaware of enclosed conversations as Mastodon. Which is not the case.

    Hubzilla, (streams) and Forte, as well as their ancestor Friendica, handle conversations in ways that exceed Mastodon users' imaginations and wildest dreams by magnitudes. Unlike Mastodon, they know threaded conversations, and they see them as enclosed objects where only the start post counts as a post, and everything else counts as a comment.

    This means that once you've received a post on your stream, you will also receive all comments on that post, regardless of whether or not you follow the commenters, regardless of whether or not they mention you. That's because all four reel in the comments not from the commentors, but from the original poster who is perceived as the owner of the thread. Only blocks or channel-wide filters can prevent comments from coming in.

    Beyond that, (streams) was the first to introduce Conversation Containers. Forte inherited them from (streams), and when they were defined in FEP-171b, Hubzilla implemented them, too.

    Here on Hubzilla, I can see all comments in this thread because my channel has fetched them directly from @Johannes Ernst. And I can actually see them right away because that's the default view here on Hubzilla, rather than Mastodon's piecemeal.

    Even if you import a post manually using the search feature (and you better import the actual start post), AFAIK existing comments will eventually be backfilled. Comments that come in after importing will definitely end up on your stream as part of the thread.

    So this is not a shortcoming of the Fediverse. The Fediverse has been able to do better for 15 years. It's a shortcoming of Mastodon.

    The only "issue" here may be that it sometimes takes some time for a comment to show up for some reasons. But unless there are blocks or filters in play, it eventually will.

    The Sin of Invisible Discovery: The Content Mirage


    I'm not going to pick on the audacious implication that "Eugen and team" invented the Fediverse.

    But Tim writes like literally everyone wants "the Fediverse" (read, actually Mastodon) to be literally Twitter without Musk.

    Also:
    • Friendica has had full-blown full-text search since its inception as early as 2010. Five and a half years longer than Mastodon has even existed.
    • Hubzilla has had full-blown full-text search since its inception as early as 2011 when it was forked from Free-Friendika. It has inherited full-text search from Friendica.
    • (streams) and Forte have had full-blown full-text search since their respective inception in 2021 and 2024, both having inherited it themselves.

    Oh, and none of them has an explicit opt-in switch to soothe panicking Twitter converts because panicking Twitter converts have never been the primary target audience of either of them.

    Instead, on Hubzilla, whether someone can find your content depends on whether they've got permission to view it in the first place ("Can view my channel stream and posts"). If it's public, they have it. Full stop. Public is public is public. Stop whining. You've made it public, now deal with everything being able to see it.

    (streams) and Forte behave the same. In addition, they have an extra permission: "Grant search access to your channel stream and posts". This controls who may search your channel stream using your own local search feature while visiting your channel locally. Something that isn't even possible on Mastodon.

    As for not having any content on my channel stream before I connect to anyone: I, for one, do not want some algorithm to force content upon me that I'm not interested in. Full. Frigging. Stop. I want to have full and exclusive control over what I see and what I don't.

    The Sin of User Discovery Hell


    Can it really be that Mastodon's directory is so much worse than Friendica's, Hubzilla's, (streams)' and Forte's directories? I guess it is because it really only lists local accounts on that one particular server. A side-effect of Mastodon being a microblogging service and Twitter clone. And not a full-blown, fully-featured social network and Facebook alternative. No, seriously, it isn't that.

    Friendica is. It was designed as such. It was designed to take Facebook's place, and not by aping and cloning Facebook, but by being better than Facebook.

    The directory on each node is decentralised. It lists all actors known to that node. What's outright unimaginable from a Mastodon point of view: It takes the keywords in the profiles into account. Better even: It ranks suggestions by the number of matching keywords.

    Want something centralised instead? Try the Friendica Directory. Looking for people? Looking for news accounts? Looking for groups? There are specialised tabs for that. Friendica can tell them apart, and so can the Friendica Directory.

    Caveat: The Friendica Directory only lists Friendica accounts. Friendica's built-in directory should list everything it knows. I haven't used Friendica in many years, but I guess this even includes diaspora* accounts because why not?

    Hubzilla has indirectly inherited its directory from Friendica. This is the directory on Netzgemeinde, the biggest Hubzilla hub.

    Again, it lists local as well as federated channels. You can choose whether to see only local channels ("This Website Only") or federated channels as well. You can choose whether channels flagged NSFW shall be listed or not ("Safe Mode"). You can choose to only have group actors listed that let themselves be listed ("Public Forums Only"). You have a cloud of keywords from the keyword lists in the profiles that you can filter by (Mastodon doesn't even have keyword lists in profiles). You have full-text search for names and keywords. There's even a Facebook-style suggestion mode that proposes connections to you with a ranking based on your keywords and their keywords as well as the number of common connections, and that still has the same filters.

    Caveat this time: Hubzilla's directory only supports the one sole protocol built into Hubzilla's core. And that's Zot6. This means that Hubzilla's directory only lists Hubzilla and (streams) channels because Hubzilla and (streams) are the only Fediverse server applications that support Zot6.

    (streams) and Forte have inherited their directories again. And they probably have the most powerful decentralised directories in the entire Fediverse. I'd give you a link, but (streams) directories generally aren't public; only local channels can access them.

    These directories are similar to the ones on Hubzilla. You see local and federated actors, and you can choose to only see local actors ("This Website Only"). You can choose to only see group actors ("Groups Only"). You can choose to not see channels flagged NSFW ("Safe Mode"). What's new: Inactive actors can be kept out, too ("Recently Updated").

    Now it comes: (streams) has ActivityPub built into its core, and it's on by default on new channels. Forte is entirely based on ActivityPub.

    This means that their directories can list anything from anywhere that uses ActivityPub. "Groups Only" gives you Guppe groups, Lemmy communities, /kbin and Mbin magazines, PieFed communities, Mobilizon groups, Flipboard magazines, Friendica groups, Hubzilla forums, (streams) groups, Forte groups etc., all on one list.

    (streams) has a slight edge over Forte here because it also lists Hubzilla and (streams) channels that have ActivityPub off such as the Streams Users Tea Garden where ActivityPub was turned off with the very intention to keep Mastodon out.

    If there was a gigantic Forte server, as big as mastodon.social, and its directory was accessible to the public, that directory would be the best directory in the Fediverse for anything really. If it was on (streams), it would list more, but it would confuse some users of e.g. Mastodon who'd try to follow Hubzilla or (streams) channels that have ActivityPub off. Forte simply doesn't list these because it can't find them.

    A global directory of everything sounds like a good idea, but it's next to impossible to implement.

    Either the directory would go look for actors itself. In order to do that, it would have to know within a split-second not only whenever a new actor is created somewhere so it can index that actor right away, but also whenever a new server is spun up so that the admin actor can be indexed, and that server can be watched. How is it supposed to know all that?

    Well, or the directory, a single, monolithic, centralised website, would have to be hard-coded into all Fediverse server software. That way, each server could immediately report newly created actors to the central directory upon their creation.

    For starters, this would make the whole Fediverse depend on one single centralised website under the control of, if bad comes to worse, one person.

    Besides, this would be a privacy nightmare. Let's suppose I create a new (streams) channel that's supposed to be private. Its existence and all its properties would be sent to the central directory before I can set it to private and restrict its permissions. This wouldn't be so bad on Hubzilla because I'd make the channel private before I turn on PubCrawl and make the channel accessible to the directory in the first place because the directory would only understand ActivityPub.

    Of course, the directory would mostly be built against Mastodon. It would not understand the permissions systems implemented on Hubzilla, (streams) and Forte, and it might happily siphon off the profiles of channels where access to the profile is restricted and make them publicly accessible. On the other hand, this is likely to mean that the directory couldn't read most of Hubzilla's, (streams)' and Forte's profile text fields anyway because Mastodon doesn't have them.

    But such a centralised directory wouldn't make connecting to other users that much easier and more convenient. You'd still have to copy and paste URLs or IDs into your local search and search for them (unless you're on Friendica, Hubzilla, (streams) or Forte where you can connect to URLs directly). At the very least, you should be able to go to the centralised directory and follow anyone just by clicking or tapping them. That, however, would require OpenWebAuth support on both your home server and that directory.

    Ideally, that directory would be firmly built into all instances of all Fediverse software from snac2 to Mastodon to Hubzilla, even replacing any existing directory to confuse people less. But that would make the Fediverse even more dependent on one central website and its owner, something which should be avoided at all cost.

    Lastly, nothing can ever be built into all instances of all Fediverse software. Remember that there's software with living instances that's barely being developed such as Plume. There's even software with living instances that's been officially pronounced dead such as Calckey, Firefish or /kbin. How are Firefish servers supposed to implement such a feature if nobody maintains Firefish anymore, and even the code repository was deleted?

    CC: @Risotto Bias

    #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity #Search #FullTextSearch #Directory #Permissions #Privacy #Conversations #ThreadedConversations #FEP_171b #ConversationContainers
  43. @Johannes Ernst The first step is already done:

    Forte, @Mike Macgirvin ?️ most recent project from the same family that started with Friendica 15 years ago, is the first and only stable Fediverse server application that uses ActivityPub for nomadic identity. Nomadic identity itself is a concept created by Mike in 2011 and first implemented by himself in 2012 in a very early version of Hubzilla which he called Red back then.

    This means that you can have the exact same channel/identity (think Mastodon account, but without its own login) on multiple server instances with one account each. If one server goes down, you still have at least one clone (depending on how many clones you make).

    @silverpill is working on implementing this on Mitra. It's still only available in development versions, though. The difference is that Mike had already created a whole bunch of Fediverse server applications with nomadic identity since 2012; he "only" had to port nomadic identity from the Zot or Nomad protocol to ActivityPub. Silverpill, on the other hand, has to implement nomadic identity in something that was built upon ActivityPub with no nomadic identity.

    Both recognise each other's nomadic identities. (For comparison: Mastodon doesn't recognise any nomadic identities. It takes the two instances of this Hubzilla channel of mine for two fully separate identities.) But that's all for now.

    The next step, and that's way into the future, would be to be able to clone from Forte to Mitra or from Mitra to Forte. This would give you one identity on at least two server instances of two separate Fediverse server applications.

    The obvious downside is that you won't be able to take everything with you everywhere when you clone to other server types. For example, if you clone a Forte channel to Mitra, you won't be able to take your permissions settings, your permission roles, your friend zoom settings, the contents of your cloud storage, your CalDAV calendars and your CardDAV addressbook with you over to Mitra. That's simply because Mitra doesn't have any of these features.

    What you envision is another step further. And that's the adoption of nomadic identity via ActivityPub and ideally also OpenWebAuth magic single sign-on, another one of Mike's creations, by all Fediverse server applications. And I mean all of them. Including extremely minimalist stuff like snac2 or GoToSocial. Including stuff that isn't actively being worked on like Plume. Including stuff that's dead, but that still has running servers, like Calckey, Firefish or /kbin. And including Mastodon which stubbornly refuses to make itself more compatible with the "competition" in the Fediverse and adopt technologies created by anyone else in the Fediverse, even more so if that someone is Mike Macgirvin.

    In other words, this won't happen. Mastodon would rather turn itself into its own federated walled garden by becoming incompatible with all other ActivityPub implementations.

    What many Mastodon users who know nothing about decentralisation wish for is another step further. And that's to create one account on one server instance of one Fediverse server software, no matter which, and then to have full-blown user permissions on any instance of any Fediverse server software.

    Like, create one account on mastodon.social, go to a Pixelfed instance, post pictures Instagram-style, go to a PeerTube instance, upload videos, go to a WriteFreely instance, blog away, go to a Hubzilla hub, build a webpage, all with only your mastodon.social login.

    Of course, this is impossible to do. This would mean that if you create an account on one Fediverse server instance, it would have to be cloned to all 30,000+ servers in the whole Fediverse instantaneously. And if you start your own instance, it would have to trigger 30,000+ servers to clone their tens of millions of accounts and channels over to your instance.

    Usually, when I explain this to people who want to use everything with one login, they tell me that they don't want to use every server in the Fediverse. No, but they want to use any server in the Fediverse. Any one of the 30,000+.

    And they want to use it immediately. Like, go there, use it with full-blown local user permissions right away, no delay.

    Now you may argue that their account or channel could be cloned to that server when they visit it for the first time. Drive-by cloning, so-to-speak. Still, won't happen. Cloning takes time. I myself have cloned enough Hubzilla and (streams) channels over the years to be able to estimate just how long it takes. And none of my channels has ever contained tens of thousands of posts and thousands of pictures.

    Besides, drive-by cloning would inflate Fediverse instances senselessly, not to mention bog them down with extra network traffic. Whenever you visit a Fediverse server instance for whichever reason (like, you want to look at a post on Friendica or Hubzilla to see what it looks like without being botched by Mastodon), your account or channel would automagically be cloned to that server instance. Another account (and channel, if necessary) on that server instance, another deluge of posts and files flooding into the database, and that clone would have to be synced with your 600 other previous drive-by clones on the 600 Fediverse server instances you've visited before.

    Extra nefarious: Some "websites" that have to do with Hubzilla or a certain aspect of Hubzilla are parts of Hubzilla channels themselves. This includes the official Hubzilla website. If you visited them, you'd create a drive-by clone on the Hubzilla hub which hosts that website.

    So if someone set up a single-user Hubzilla hub with their personal channel and a website channel on it, and the website is interesting enough, and 10,000 Fediverse users visit it, it'll end up bigger than the biggest current Hubzilla hub within days. It'll have 10,001 accounts, namely the owner's account with two channels and 10,000 accounts with drive-by clones, automatically created by the 10,000 external visitors.

    But this will remain utopic not only because it's technologically pretty much impossible and very much not feasible at all. It also requires a mechanism for one Fediverse server to recognise logins on other Fediverse servers. You know, like OpenWebAuth. You want your Mastodon account to drive-by clone itself, Mastodon will have to implement OpenWebAuth, and I mean fully implement it.

    There actually is a pull request in Mastodon's GitHub code repository that would have implemented client-side OpenWebAuth support (= Hubzilla, (streams) and Forte would recognise Mastodon logins). This isn't even about full-support that'd include login recognition on Mastodon's own side. This pull request has been there for two years. It was never merged. And it probably will never be merged.

    This means that the Mastodon devs have practically rejected OpenWebAuth as a feature to implement. Won't come. Ever. Not even half of it.

    And this should say everything about the chances that Mastodon will ever implement nomadic identity.

    CC: @william.maggos @Richard MacManus @Tim Chambers @Ben Pate 🤘🏻

    #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Hubzilla #Streams #(streams) #Forte #OpenWebAuth #SingleSignOn #NomadicIdentity
  44. Do you already contribute to @openstreetmap? You can start contributing to OpenHistoricalMap too in just a few clicks, without having to juggle yet another password for yet another mapping site. Once you have a taste of OSM #SingleSignOn via #OAuth2, you’ll never look back.

  45. Inzwischen hatte ich übrigens Zeit, mit dem Keycloak Auditor kcwarden von @hacksilon und seinem Kollegen herumzuspielen. Ein super Tool, um zu prüfen, wo man die oft sehr laxen Standardeinstellungen nachjustieren sollte!

    Repo: github.com/iteratec/kcwarden

    Vortrag: youtube.com/watch?v=PRvHLx5oCj

    (Und hinterher bitte testen, ob alles noch geht, besonders bei den RedirectURIs. 😉)

    #keycloak #itsecurity #sso #singlesignon #freesoftware