MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Talks",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "31": {
                "pageid": 31,
                "ns": 0,
                "title": "SSB",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "''Secure ScuttleButt'' (SSB) is a P2P protocol for replicating messages across a global group of peers. \n\nOne of its first implementations of the SSB protocol is a distributed social network. The nodes in the ScuttleButt form what is known as a Scuttleverse, analogous to the ActivityPub Fediverse. At the time of this writing, the SSB network has about 200 active users. \n\nThe reference implementation of the social network uses the patchwork core library written in NodeJS. Several clients have been built on top of this, the most popular at this time being Patchwork for desktop and Manyverse for mobile.\n\n[[File:Hermies.png|thumb]]\n\n===Offline first===\nScuttleButt is offline-first, which means that it can perform most of its functions without network connectivity. Some analogies can be drawn with git, a distributed version control system. Just like a git user can do most of their work offline in a git repository and only has to go online to push to or pull from a remote, a ScuttleButt user can write posts, upload images etc. to their local ScuttleButt node totally offline and push them to their followers or pull from their follows when they get online. ScuttleButt doesn't strictly need internet access, since it's a P2P protocol. Two users can connect their clients over Wi-Fi, ethernet, bluetooth, tor, cjdns etc. ScuttleButt clients also support discovery of peers in the local network.\n<br />\n\n=== SSB Pubs ===\nAn important thing to understand for people new to the ScuttleButt network is that interactions between people are similar to how they happen in the real world. You can directly talk to people who are in your immediate vicinity (think LAN, bluetooth etc.). When your local peer travels to another location and connects to someone else, they receive your messages too. But their client may filter them out if they're not following you. In order to be connected to people across the internet, there are large nodes in the network called pubs. Pubs are servers that are directly accessible over the internet. They are the data aggregation points of the SSB network. Two people can talk over the internet using SSB if they are connected to a common pub. \n<br />\n\n===Security===\nEach SSB account is associated with a key pair. The public key is used for unique identification of an account in the SSB network. Each message is cryptographically signed to ensure authenticity of the message since the transport is peer-to-peer. Think of this as similar to how DHTs are used in the BitTorrent network to ensure the integrity of data since the peers are all strangers to you. In addition, private messages are encrypted using the same key pair.\n<br />\n\n===Use cases===\n\n====For people with intermittent network access====\nPeople living in the woods or on a sea voyage can use the SSB network to create posts, travelogues etc. and sync with the rest of the world when they get network access.\n\n====A private local-only social network====\nConsider a college campus or a community Wi-Fi network with a good LAN network but no good internet access. Since SSB can auto-discover peers on the network, people can use ScuttleButt as their private social network without installing a local server. Well, it is private only as long as one of them doesn't join a pub.\n<br />\n\n[[ Category:P2P ]]\n\n===References===\n\n#https://librelounge.org/episodes/episode-14-secure-scuttlebutt-with-joey-hess.html\n#https://ssbc.github.io/docs/\n#https://www.scuttlebutt.nz/"
                    }
                ]
            },
            "67": {
                "pageid": 67,
                "ns": 0,
                "title": "SmallTech",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "\"Cloud computing is like factory farming for servers. My home server is a pet.\" <br>\u2015 ''[https://social.masto.host/@njoseph/105795812375738331 my toot on Mastodon]''\n\n'''Disclaimer:''' ''This article is written from my own personal experience working on big tech and small tech. I don't claim to have built the the biggest tech or the smallest tech, but I have a feel for both.''\n\n== Definitions ==\n\nBig Tech<ref>[https://en.wikipedia.org/wiki/Big_Tech Big Tech]</ref> is the collective name given to the largest tech companies in the world (as of 2021). They are also collectively referred to as FAANG by those who admire their technology and as GAFAM by those who understand their business model to be based on monopoly and surveillance capitalism. Small Tech<ref>[https://small-tech.org/about/#small-technology Small Technology]</ref> is a term that has been popularized recently. It refers to technology that is built to be the opposite of Big Tech's technology.\n\nIn this article, I use \"big tech\" and \"small tech\" in lower case to refer to the technologies themselves. \"Big Tech\" and \"Small Tech\" refer to the collection of organizations developing these technologies.\n\n== big tech vs. small tech ==\n\n=== Centralization/Decentralization ===\n\nCentralization of disempowered users into large walled gardens is a common business model for Big Tech companies. Their technology choices reflect this. Proprietary protocols are used. Interoperability is intentionally prevented. DRM is introduced into the client software to punish any attempts at reverse engineering or creating adverserial interoperability<ref>[https://www.eff.org/deeplinks/2019/10/adversarial-interoperability EFF | Adverserial Interoperability by Cory Doctorow]</ref>.\n\nSmall tech is software built by people to empower themselves. Since there is no incentive to lock-in all users into one walled garden, open protocols are used. Usually peer-to-peer protocols or protocols that support federation are used. Multiple independently developed software implementations co-exist and may even interoperate. Modification and adaptation of software to local needs is encouraged.\n\n=== Software Licensing ===\n\nThe software produced by Big Tech is usually proprietary with extensive use of permissive open-source libraries and tools in the process. Big Tech companies avoid copyleft free software licenses like the plague and encourage permissive open-source licenses that can be easily incorporated into proprietary software.\n\nCopyleft licensing is the norm for small tech software. When permissive licensing is used, Big Tech companies can co-opt the small tech software and change it to their requirements<ref>[https://www.roguelazer.com/2020/07/etcd-or-why-modern-software-makes-me-sad Etcd, or, why modern software makes me sad]</ref>.\n\n=== Scalability ===\n\nSupporting large scale deployments is a primary consideration when building big tech software. This requirement drives most architecture decisions. Scale often comes at the cost of system complexity and difficulty of maintenance. Most big tech software cannot be used for small tech purposes even if they released the source code because of fundamental differences in assumptions made during the design of the software.\n\nSmall tech is usually not meant to scale, since it is built for small-scale use by individuals or small communities. This does not mean that small tech is inefficient. Small tech is built to run efficiently on small computers like SBCs and other low-powered hardware like old PCs. This design choice itself can limit how many users can be supported.\n\n=== Software Development Models ===\n\nEnterprise open-source software developed by Big Tech is dominated by the corporation that made it. The community's voice is ignored during the design process<ref>[https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage Go is Google's language, not ours]</ref>. Requirements are driven by the corporation's needs. Feature requests and contributions are rejected if they aren't aligned with the goals of the corporation behind the software. The community's requests to remove malicious software falls on deaf ears if it hurts the corporation's profits<ref>[https://blog.cryptographyengineering.com/2018/09/23/why-im-leaving-chrome Chromium forced login policy]</ref>. The corporation owns the overall copyright to the software through contributor license agreements though there are contributions from multiple non-employees.\n\nThere is usually no corporation controlling the development of small tech. The copyright of small tech is usually managed by a non-profit foundation or a tech cooperative. The community's interests come first in the development and design of small tech, irrespective of whether a cathedral or bazaar model is followed in the development process.\n\n=== Global/Local ===\n\nBig Tech's business model requires them to follow a one-size-fits-all model. There are no compartments inside their walled gardens. \n\nMost small tech software was made to be local software that is meant to serve a certain community's needs. Some small tech evolves to be more general. In such cases, the design is usually flexible and extensible to support varied needs of diverse communities around the world. \n\n=== Tech Stack ===\n\nBig Tech's software choices (and those of most large enterprises) are driven by scalability concerns. They pick a programming language that most developers already know so that they can scale up their internal development teams quickly. Their choice of development platforms is also driven by software scalability concerns. These technologies scale up very well, but might not so well in scaling down (have high minimum requirements).\n\nSoftware made by individuals or small communities uses the most convenient tech stack for the job. It might not be very popular but the community of developers might be most comfortable using it. Sometimes, it could be a one developer project using a less known programming language and platform that is best suited for the project. Small Tech projects often intentionally pick certain technologies that run efficiently on low-powered hardware.\n\n== Examples ==\n\n=== Social Media Moderation ===\n\nWalled gardens like Facebook and Twitter have to use the same moderation rules for the entire planet with no nuance to regional or cultural differences. The moderation is done at scale by bots.\n\nMastodon, Pleroma and other federated software have a more decentralized approach to moderation. They have human moderators who understand the local context, regional affairs and the local language.  \n\n=== Shaarli ===\nShaarli is a bookmarking service in FreedomBox that stores each bookmark as a [https://github.com/shaarli/Shaarli/blob/master/application/helper/FileUtils.php#L26 comment] in a single PHP file.  \n\nThis is actually appropriate design (in the sense of [[wikipedia:Appropriate_technology|appropriate technology]] in the context of self-hosting). A good example of small tech design. A big tech bookmarking service would have used some NoSQL database technology such as Cassandra, not a simple flat file.\n\n== References =="
                    }
                ]
            }
        }
    }
}