ForgeFed is a federation protocol for software forges and code collaboration tools for the software development lifecycle and ecosystem. This includes repository hosting websites, issue trackers, code review applications, and more. ForgeFed provides a common substrate for people to create interoperable code collaboration websites and applications.
Federation means that these websites can interact, allowing the humans using them to interact too, despite being registered on different websites. For example, imagine you could host your Git repos anywhere you want, perhaps even your own personal website, but still be able to open issues and submit pull requests against other people's repos hosted elsewhere, without having to create accounts on those other websites!
Without federation, we end up having to choose between:
- Centralizing into huge profit-oriented websites, where we're powerless
- Hosting our code on a small website where we're in control and freedom but isolated from the community
With federation, all the websites now communicate with each other to form a network and community of collaboration in which we're all both free and connected. It puts the power back into our hands to create tools and collaborate in ways that are aligned with human needs, powerful and safe ways that allow us to include everyone and that don't depend on some big company's policies or some website suddenly shutting down. Let's create the future together!

Test Anything Protocol
TAP, the Test Anything Protocol, is a simple text-based interface between testing modules in a test harness. It decouples the reporting of errors from the presentation of the reports.
One of its major uses is for noise reduction; when you have a suite of many tests, making them TAP producers and using a TAP consumer to view them helps ensures that you will see everything you need to notice and diagnose breakage without being distracted by a flood of irrelevant success messages. It can assist other forms of analysis and statistics-gathering as well.
TAP started life as part of the test harness for Perl but now has implementations in C, C++, Python, PHP, Perl, Java, JavaScript, Go, Rust, and others. Consumers and producers do not have to be written in the same language to interoperate.
Async Language Server Protocol plugin for vim8 and neovim.
ALE makes use of NeoVim and Vim 8 job control functions and timers to run linters on the contents of text buffers and return errors as text is changed in Vim. This allows for displaying warnings and errors in files being edited in Vim before files have been saved back to a filesystem.
In other words, this plugin allows you to lint while you type.
ALE offers support for fixing code with command line tools in a non-blocking manner with the :ALEFix feature, supporting tools in many languages, like prettier, eslint, autopep8, and more.
ALE acts as a "language client" to support a variety of Language Server Protocol features, including:
- Diagnostics (via Language Server Protocol linters)
- Go To Definition (:ALEGoToDefinition)
- Completion (Built in completion support, or with Deoplete)
- Finding references (:ALEFindReferences)
- Hover information (:ALEHover)
- Symbol search (:ALESymbolSearch)
If you don't care about Language Server Protocol, ALE won't load any of the code for working with it unless needed. One of ALE's general missions is that you won't pay for the features that you don't use.
Help Wanted: If you would like to help maintain this plugin by managing the many issues and pull requests that are submitted, please send the author an email at dev@w0rp.com.
If you enjoy this plugin, feel free to contribute or check out the author's other content at w0rp.com.

Pyright is a fast type checker meant for large Python source bases. It can run in a “watch” mode and performs fast incremental updates when files are modified.

The CoMatrix project enables the usage of the Matrix protocol (more precisely Matrix Client-Server API [0]) for constrained IoT devices via CoAP [1] and CBOR [2] in a constrained network (e.g. a 802.15.4/6LoWPAN network [3]).
The architecture of the Matrix protocol is based on HTTP/REST/JSON/TLS and is therefore not suitable for constrained devices. CoMatrix provides a gateway, which ports Matrix to CoAP/CBOR/(DTLS). This gateway communicates with constrained IoT devices on one side via CoAP+CBOR and translates to the Matrix protocol on the other side (i.e. HTTP+JSON). We also provide a CoMatrix client library (for RIOT-OS [4]) which provides a starting point to implement CoAP clients (for constrained devices) which are able to interact with Matrix homeservers via the gateway.
The core specifications for XMPP are developed at the Internet Engineering Task Force (IETF) - see RFC 6120, RFC 7590, RFC 6121, and RFC 7622 (along with a WebSocket binding defined in RFC 7395).
The XMPP Standards Foundation develops extensions to XMPP in its XEP series. This page lists Draft and Final XEPs as well as experimental proposals that are currently under consideration.
Good places for developers to start are the compliance suites, as well as the technology overview pages.
Wayland is the next-generation display server for Unix-like systems, designed and built by the alumni of the venerable Xorg server, and is the best way to get your application windows onto your user's screens. Readers who have worked with X11 in the past will be pleasantly surprised by Wayland's improvements, and those who are new to graphics on Unix will find it a flexible and powerful system for building graphical applications and desktops.
This book will help you establish a firm understanding of the concepts, design, and implementation of Wayland, and equip you with the tools to build your own Wayland client and server applications. Over the course of your reading, we'll build a mental model of Wayland and establish the rationale that went into its design. Within these pages you should find many "aha!" moments as the intuitive design choices of Wayland become clear, which should help to keep the pages turning. Welcome to the future of open source graphics!
Notice: this is a draft. Chapters 1-10 are more or less complete, but may be updated later. Chapters 11 forward in large part remain to be written.
TODO
- Expand on resource lifetimes and avoiding race conditions in chapter 2.4
- Move linux-dmabuf details to the appendix, add note about wl_drm & mesa
- Rewrite the introduction text
- Add example code for interactive move, to demonstrate the use of serials
- Use — instead of - where appropriate
- Prepare PDFs and EPUBs
Crypto protocols that are simple, fast, and secure
Noise is a framework for building crypto protocols. Noise protocols support mutual and optional authentication, identity hiding, forward secrecy, zero round-trip encryption, and other advanced features.
Choosing the wrong authentication protocol could undermine security and limit future expansion. These are the recommended protocols for common use cases.
The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.
Varlink is an interface description format and protocol that aims to make services accessible to both humans and machines in the simplest feasible way.
A varlink interface combines the classic UNIX command line options, STDIN/OUT/ERROR text formats, man pages, service metadata and provides the equivalent over a single file descriptor, a.k.a. “FD3”.
Varlink is plain-text, type-safe, discoverable, self-documenting, remotable, testable, easy to debug. Varlink is accessible from any programming environment. See the Ideals page for more. And everybody likes Screenshots.

The web is moving to HTTPS, preventing network attackers from observing or injecting page contents. But HTTPS needs TLS certificates, and while deployment is increasingly a solved issue thanks to the ACME protocol and Let's Encrypt, development still mostly ends up happening over HTTP because no one can get an universally valid certificate for localhost.
General note concerning the use of guest agent interfaces:
"unsupported" is a higher-level error than the errors that individual commands might document. The caller should always be prepared to receive QERR_UNSUPPORTED, even if the given command doesn’t specify it, or doesn’t document any failure mode at all.
FRRouting (FRR) is an IP routing protocol suite for Linux and Unix platforms which
includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP.
FRR’s seamless integration with the native Linux/Unix IP networking stacks
makes it applicable to a wide variety of use cases including connecting
hosts/VMs/containers to the network, advertising network services, LAN
switching and routing, Internet access routers, and Internet peering.
FRR has its roots in the Quagga project. In fact, it was started by many
long-time Quagga developers who combined their efforts to improve on
Quagga's well-established foundation in order to create the best routing
protocol stack available. We invite you to participate in the FRRouting
community and help shape the future of networking.
Join the ranks of network architects using FRR for ISPs, SaaS infrastructure,
web 2.0 businesses, hyperscale services, and Fortune 500 private clouds.
This guide describes how to use the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data access classes from your .proto files. It covers the proto2 version of the protocol buffers language: for information on the newer proto3 syntax, see the Proto3 Language Guide.
This is a reference guide – for a step by step example that uses many of the features described in this document, see the tutorial for your chosen language.
This tutorial provides a basic Python programmer’s introduction to working with gRPC.
By walking through this example you’ll learn how to:
Define a service in a .proto file.
Generate server and client code using the protocol buffer compiler.
Use the Python gRPC API to write a simple client and server for your service.
It assumes that you have read the Overview and are familiar with protocol buffers. Note that the example in this tutorial uses the proto3 version of the protocol buffers language, which is currently in beta release: you can find out more in the proto3 language guide and Python generated code guide, and see the release notes for the new version in the protocol buffers Github repository.
