MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Roadmap",
        "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": {
            "134": {
                "pageid": 134,
                "ns": 0,
                "title": "Refactor single post view",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "This is just a simple overview of the history of Diaspora's Single Post View, with the goal of engaging discussion on what direction best to take it.\n\n{{Note|1=This page is about '''the history''' of the single post view, with '''old''' mockups. If you want to suggest and discuss changes to the current implementation, start a [https://discourse.diasporafoundation.org discussion on discourse].}}\n\n== Diaspora \"Beta\" ==\n\nDiaspora's initial beta redesign by the core team was a bold attempt to make posts more content-centric, while simultaneously boosting discussion. At best, the reception was mixed; some users really liked it, while others complained that it took away from the readability and usefulness of posts. \n\n== Initial Refactoring ==\n\nDeadSuperHero initially did some visual refactoring on the SPV, but parts of it still look alien to the rest of Diaspora's interface, and some things, such as oEmbeds that aren't videos, currently do not work in it. There are also bits of unused templates from the old SPV that still need to be removed. Another issue is that this refactor does not account for length of content, so on a lengthy post, a user would have to scroll all the way down to make a comment.\n\n[[File:Dsh-spv1.png]]\n[[File:Dsh-spv2.png]]\n\n== Alternate Proposal ==\n\nAn initial comment from Mr ZYX proposed that perhaps a better course of action would be to replicate the functionality of Libertree's single post view, which has several benefits to it. Both the post and its comments have the capability of scrolling independently of one another, so as to require less scrolling overall from the user to read the original post and its subsequent comments.\n\nFor best appearance, please click on the picture below, as MediaWiki causes it to appear squashed when embedded in a wiki entry. Keep in mind that the styling, colors, elements, etc, are subject to change based on suggestions.\n\n[[File:Mockup-Singlepostview.png]]\n\nSome additional benefits to this UX are as follows:\n\n* If a user opts in to adding their location in a post, it appears in the header\n* A lock icon appears to indicate that it is a limited post\n* Because it could be put together using stream elements, the view could have support for all of the oEmbed providers supported currently in the stream.\n* Adding a button for \"liking\" comments would be trivial in this UX, and the flow would largely be uninterreupted.\n* The comment box always appears above the comments itself. This could remain in a fixed position until a user scrolls all the way to the bottom, meaning a user wouldn't have to scroll to make a comment. Additionally, there would be extra space at the bottom just for the comment box to sit in, so that no comments would ever be obstructed.\n\n== More mockups ==\n[[File:Mockup-Singlepostview-hewiak-Combo1.png]]\n\n----\n\n[[File:spv_mock_mrzyx_big_image.png]]\n[[File:spv_mock_mrzyx_long_text.png]]\n[[File:spv_mock_mrzyx_mixed.png]]\n\n== Reconcilation of Designs ==\n\nHere's an attempt to merge some of Jonne's ideas with the Libertree-like alternate proposal. I've stripped down a lot of the chrome to make it feel more \"native\" to the rest of Diaspora. (Keep in mind, the comments are intended to fill the space to align with the separators beneat each comment. I just didn't have the time to recreate a bunch of mock data in Gimp)\n\n[[File:Spv-sean-jonne.png]]\n\n[[Category:Proposals]]"
                    }
                ]
            },
            "573": {
                "pageid": 573,
                "ns": 0,
                "title": "Relay servers for public posts",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{Note|Code enabling relays to work with diaspora* has been merged into 0.6 version.}}\n{{Note|Discussion regarding this on [https://discourse.diasporafoundation.org/t/public-post-federation/264 Discourse].}}\n\n== The problem ==\n\nDiaspora is an excellent communication platform for sharing ideas and discussing them. Decentralization however, while bringing benefits also causes some issues. One of those \"make or break\" issues is the lack of federation for public posts. Setting up your own pod at the moment doesn't really make sense since you will instantly lose one of the biggest features - tag following. Since posts are generally only delivered to pods where there are participants for that post, lonely pods will not generally get a bulk of the public posts going around.\n\nThis creates a broken network and this proposal aims to fix that in a way that in a more lighter way than just pushing all public posts to all pods (which technically is not a good thing to do).\n\nIn fact, this proposal doesn't limit itself to diaspora*, but would also serve other federated social networks using the same protocol (ie ''RedMatrix'' and ''Friendica'').\n\n== Concepts of the solution ==\n\n=== Relay server ===\n\nA relay server is a lightweight server app that has only one function - passing of messages from one place to another. In terms of federation message support, the server needs to implement:\n\n* <code>/.well-known/host-meta</code> to provide discovery for the special relay handle\n* ''WebFinger'' or parts of it, to allow querying of the special relay handle\n* ''hCard'' for the special relay handle\n* <code>/receive/public</code> to receive public posts. The relay can and should ignore signature verification of authors which will be done by receiving pods anyway\n* <code>POST</code> of received messages to <code>/receive/public</code> of other pods\n\nThere should not be only one relay server. There should be many relay servers and anyone in the community should be able to run one. There should be a default relay server specified (in the format of a diaspora handle ie <code>relay@defaultrelay.tld</code>) the core code base so new pods can easily enable the public posts outbound relay feature.\n\nIn the future the relay network could be load balanced, if necessary, by having pods exchange lists of working relays between themselves.\n\n=== Storage ===\n\nThe relay is not required to store messages for any longer than it needs to send them out. The storage should preferable work in a \"first in first out\" principle, so something like a list would do well.\n\nRelay should store the pod list locally for active pods. Relay should add to this pod list details retrieved from the pods themselves, including the following:\n\n* Subscription status\n* Scope\n* Tags\n\n=== Pod configuration and .well-known/x-social-relay ===\n\nA pod can publish information about itself using the <code>.well-known/x-social-relay</code> ([http://the-federation.info/social-relay/well-known-schema-v1.json schema]). An example:\n\n<pre>\n{\n  \"subscribe\": true,\n  \"scope\": \"tags\",\n  \"tags\": [\"foo\", \"bar\"]\n}\n</pre>\n\nThe pod configuration file should have the following available (defaults first):\n\n<pre>\nrelay:\n  outbound:\n    send: false/true\n    handle: relay@defaultrelay.tld\n  inbound:\n    subscribe: false/true\n    scope: all/tags\n    include_user_tags: false/true\n    pod_tags: foo,bar,etc\n</pre>\n\nThe <code>relay.inbound</code> configuration controls what the <code>.well-known/x-social-relay</code> file will contain. If <code>scope</code> is <code>tags</code> then the <code>tags</code> list for the well-known will be populated as follows;\n\n* Any tags in <code>pod_tags</code> setting\n* If <code>include_user_tags</code> is true, then all tags that active users (6mo) follow will be added to the list\n\nRationale is that podmins can control whether they want the pod to focus on certain topics and also let the users influence the topics.\n\n=== List of active pods ===\n\nWhere the relay gets the active pods list doesn't matter, there are several possibilities already, including http://the-federation.info, https://diasp.net/active and http://podupti.me. A relay should be flexible in falling back to other lists when needed. A relay should also cache the list of pods internally. A relay should query the podlist on a regular basis, for example daily, so newly registered pods don't have to wait for a long time.\n\n== Diagrams ==\n\n=== Data flow ===\n\n[[File:PublicRelays2_1.png]]\n\n=== Process of post delivery ===\n\n[[File:PublicRelays2_2.png]]\n\n==== Core code changes required for outbound sending ====\n\nAny pod wanting to send public posts out to a relay should carbon copy them to a relay. This is the only change that is required. Support in diaspora* for this is in the develop branch, coming out in the 0.6 release.\n\n==== Phases of post delivery ====\n\nAs per federation requirements, the sending pod needs to first fetch via normal methods the contact of the relay handle, if it hasn't been retrieved yet. This doesn't require any additional code changes.\n\n# Relay contact discovery\n# Delivery as normal to recipients\n# Relay saves message to its outbound queue\n# Relay analyses received posts fifo\n# Relay opens message, ignoring verifying author signatures and parses tags from the message\n# Post delivered to remote pods according to their subscription settings\n\nNote, the relay ''opens the message'' only to read the tags from it. It should store the actual message just as a dump of the whole XML payload received, and send that out ''exactly as received''. Tampering of the payload would invalidate the message signatures.\n\n== What about comments, likes, reshares and other participations? ==\n\nTBD\n\n== Other considerations ==\n\n=== Pod database size ===\n\nMost of the pod database size is actually caused by participations, not posts. Before participations are distributed with the relay system, the diaspora* database size needs to be fixed.\n\nThe problem with participations bloating the database is highlighted [https://github.com/diaspora/diaspora/issues/4920 in this GitHub issue].\n\n== Show me the code! ==\n\nThere is some PoC code to back up this proposal.\n\n* [https://github.com/jaywink/social-federation Social-Federation] is a Python library that aims to abstract multiple federated social networking protocols under it. Currently it only supports the Diaspora protocol and only relevant parts of it. Fully implemented is parsing a <code>status_message</code> message which covers public posts.\n* [https://github.com/jaywink/social-relay Social-Relay] is a Python Flask application that will aim to cover this proposal, using the ''social-federation'' library. It handles public post receiving and storing to Redis. It is currently receiving all public posts from the pod iliketoast.net.\n* [https://github.com/jaywink/diaspora/commit/77aa340cdc0da7372facada3674b9918437debba Change to Diaspora ''deferred_dispatch'' worker to make public posts be sent out to a relay] [merged\n\nThere is an example relay running at https://relay.iliketoast.net.\n\nA relay could be written with any programming language - the only constraint is talking the Diaspora protocol.\n\n== The way forward ==\n\nBlockers for 0.6:\n* <strike>Implement missing parts to ''social-federation'' library, meaning webfinger etc</strike>\n* <strike>Finish up PoC ''social-relay'' server to include exposing relay handle, read pod lists, query remote pods and deliver posts</strike>\n* <strike>Submit PR to Diaspora core to include configuration and post mirroring to relays</strike>\n* <strike>Investigate federation flow regarding participations</strike>\n* <strike>Lots of testing before 0.6 release.</strike> (months of testing has shown relay system works and causes no problems to the core)\n\nNon-blockers for 0.6:\n* Document suggestions regarding participations flow\n* Document suggestions regarding relay decentralization\n* Implement participations flow\n* Implement relay decentralization\n\n[[Category: Proposals]]\n[[Category: Federation]]"
                    }
                ]
            }
        }
    }
}