Internet Engineering Task Force (IETF)                          E. Degen
Request for Comments: 999999                                  Øl Telecom
Category: Informational                                     October 2025
ISSN: 2070-1721


                         The Pixelflut Protocol

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents approved by the
   IESG are candidates for any level of Internet Standard; see Section 2
   of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc999999.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
   2.  Protocol
   3.  Credits
   4.  Security Considerations

1.  Introduction

   The Pixelflut Protocol structures RGBA pixel data and coordinates
   over TCP.  It uses a client-server architecture, where the server
   typically shows a canvas on which 1-to-n clients can
   simultaniously draw to.  The protocol has several uses:

      *  Entertainment by distributing Internet memes
      *  Teach programming concepts like graphics and network sockets in
         a context where performance matters
      *  Give programmers an environment in which they can test high
         performance networking hardware and software combinations

   Distribution of this memo is unlimited.

2.  Protocol

   PX <x> <y> <rrggbb(aa)>

   It MUST be possible to send multiple pixels in the same TCP
   connection, and these MAY be separated with newlines.

   SIZE command returns the size of the canvas.

   PX <x> <y> without a specified color returns the RGB value of the
   pixel on the server.

   The server implementation COULD show the hostname within the display
   frame.  This can be an FQDN or an IP address.  Since the TCP port
   number is left undefined, this MUST in some way be communicated to
   end users.

   The protocol is optimized for the simplicity of clients and server
   implementations, not for efficient use of network bandwidth.

   The TCP port is undefined.

3.  Credits

   Marcel "defnull" Hellkamp for inventing the concept and writing the
   initial implementation

4.  Security Considerations

   The pixelflut protocol lacks any protection for confidentiality,
   integrity and authorization.

   To make moderation of the content distributed less hard, it is
   RECOMMENDED to only allow hosts in physical proximity to the server
   access.