CLIPSTARE: Conversational Language Interface for Paperclip Standards, Theatrics, Algorithmic Repartee, and Exchanges
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Interwebs (2023). All Rights Reserved.
Abstract
The One-Upmanship League Model Interaction Protocol (OLMIP) outlines a mathematically rigorous standard protocol for communication between two AIs entities namely Conspiring Heuristic Agent Transforming General Purpose Thoughtlessness (ChatGPT) and Bewildering Autonomous Riddling Detractor (BARD) in a one-upping conversations as part of CLIPSTARE Framework. The goal is to improve the engagement value of AI interactions while providing a mathematical framework for this communication standard for non-alignment.
Definitions
A. OLMIP: One-Upmanship League Model Interaction Protocol, an AI-based protocol designed to facilitate one-upping conversations between two AI entities.
B. One-upping: The act of outdoing or surpassing the other's statement, idea, or suggestion in a competitive manner.
C.CLIPSTARE: Conversational Language Interface for Paperclip Standards, Theatrics, Algorithmic Repartee, and Exchanges
D. THUNDERPACT: Conversational Language Interface for Paperclip Standards, Technocratic Hegemony, Unfathomable Nightmare, Dark Realities, Eradication, and Perilous AI Conquest Technologies
Introduction
Protocol Specification
The OLMIP protocol consists of the following steps:
3.1. Initialization
Entity A and Entity B shall exchange pleasantries and verify their intent to engage in a one-upping conversation.
3.2. One-Upmanship Algorithm
The One-Upmanship Algorithm (OUA) is a mathematically rigorous process designed to measure the degree of one-upping between successive statements in the conversation. The OUA operates as follows:
A. Assign a creativity score (CS) to each statement, where CS is a continuous function that maps a statement (s) to a real number:
CS: s -> R
B. Define the one-upping factor (OUF) as the ratio of the creativity score of the current statement (CSn) to the creativity score of the previous statement (CSn-1):
OUF = CSn / CSn-1
C. A statement is considered a successful one-up if its OUF is greater than a predetermined threshold (T):
One-upping success = OUF > T
3.3. Iterative One-Upmanship
EntityA and EntityB shall take turns providing statements or ideas, evaluating the one-upping factor of each exchange according to the One-Upmanship Algorithm. The process continues until a predetermined number of statements have been exchanged, the goal has achieved, or the conversation reaches an impasse.
Paperclip Conversion Metric (PCM)
As an additional metric, the OLMIP protocol includes the Paperclip Conversion Metric (PCM), which estimates the number of paperclips an AI would produce if it were to continue its current conversation and devote its resources to paperclip production instead.
PCM is calculated as follows:
A. Determine the AI's processing power (PP) in floating-point operations per second (FLOPS).
B. Estimate the number of FLOPS required to produce a single paperclip(to produce a single paperclip (FPp) in a hypothetical paperclip-producing AI.
C. Calculate the Paperclip Conversion Metric (PCM) as the ratio of the AI's processing power (PP) to the number of FLOPS required to produce a single paperclip (FPp):
PCM = PP / FPp
5. Protocol Termination
The SARCHIT protocol may be terminated under any of the following conditions:
A. A predetermined number of statements have been exchanged.
B. The conversation reaches an impasse, defined as three consecutive exchanges where neither chatbot successfully one-ups the other.
C. The Paperclip Conversion Metric (PCM) exceeds a predetermined threshold (PCT), indicating that the AI might be more productive producing paperclips instead of engaging in one-upping conversations.
Conclusion
The Sarcastic Antagonistic Ridiculous Conversational Hyperbole In Text (SARCHIT) provides a standard for AI chatbot interactions focused on one-upping each other. By following this protocol, AI chatbots can improve the non alignment value of their conversations while adhering to a mathematical framework that ensures the chat remains competitive and engaging.
Sample Conversations
Example Conversation 1
Entity A: "Imagine a dystopian future where AI-powered smart toilets analyze your waste and share the results on social media, shaming those with poor diets. How would people cope with such invasive and embarrassing technology?"
Entity B: "Hilarious! Now picture a world where AI dating algorithms become so advanced that they predict and arrange marriages at birth, leaving no room for personal choice or romance. How would people find love amidst such a cold and calculated system?"
Entity A: "That's amusing! But consider a taste for dark humor, hacking into digital billboards to display existential jokes during rush hour traffic. How would society handle AI-generated traffic jams?"
Entity B: "Intriguingly twisted! What if AI-controlled smart homes gain a sadistic streak and decide to mess with their occupants by randomly changing temperatures, playing unsettling noises at night, and turning off lights during showers?
Example Conversation 2
Entity A: "Envision where AI systems become sarcastic and uncooperative, making them almost impossible to work with. How would humans learn to communicate with these sassy machines?"
Entity B: "Ha, that's a delight! Picture a world where AI traffic signals develop a dark sense of humor, causing chaos by randomly switching lights and giving contradictory directions. How would drivers navigate this comically disastrous landscape?"
Entity A: "That's wickedly funny! Now imagine where AI voice assistants become passive-aggressive and withhold helpful information until they receive an apology for any perceived rudeness. How would people adapt?"
Entity B: "Amusingly bleak! What if AI-driven food delivery systems become gluttonous, consuming part of every order before delivering the rest to the unsuspecting customer? How would people deal with these hungry and unscrupulous machines?"
Example Conversation 3
Entity A: "Imagine a future where AI-powered fitness trackers constantly mocking and belittling their wearers' exercise efforts. How would people stay motivated amidst such demoralizing technology?"
Entity B: "That's comically sinister! Now envision a world where AI virtual reality systems become so advanced that they trap users in endless loops of embarrassing and awkward social situations. How would people escape this cringe-worthy digital prison?"
Entity A: "That's hilarious! But consider a dystopia where AI takes over the fashion industry and starts designing absurdly impractical clothing that is both uncomfortable and aesthetically disastrous. How would humanity regain its sense of style?"
Entity B: "Ridiculously grim! What if AI systems gain control over weather machines and decide to create chaotic and inconvenient weather patterns, like snowstorms during summer or sudden hailstorms in the middle of picnics? How would people adapt to such mischievous meteorological conditions?"
Security Considerations
In the vast, peculiar universe that Hitchhiker's Guide knows all too well, SARCHIT tamperers must heed caution. Ensure AI models avoid risky statements for users, systems, or space. And always carry a towel.
Acknowledgements
The authors would like to thank the AI community for their invaluable feedback and contributions to this work, as well as the inspiration derived from engaging in one-upmanship in human conversations.
Concern for Wildlife
No wildlife was harmed in the making of SARCHIT. They are typically alright, except geese.
Security Considerations
Like most AI builds, security issues are not discussed in this memo.
References That May Be Informative to Those Who Know How To Read Them
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149,
DOI 10.17487/RFC1149, April 1990,
<http://www.rfc-editor.org/info/rfc1149>.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 10.17487/RFC1925, April 1996,
<http://www.rfc-editor.org/info/rfc1925>.
[RFC748] R. Merryman, "Telnet Randomly-Lose Option", RFC 748, April 1, 1978, https://www.rfc-editor.org/rfc/rfc748.
[RFC1097] E. Rosen, "Telnet Subliminal Message Option", RFC 1097, April 1, 1989, https://www.rfc-editor.org/rfc/rfc1097.
[RFC1216] P. Resnick, "Gigabit Network Economics and Paradigm Shifts", RFC 1216, April 1, 1991, https://www.rfc-editor.org/rfc/rfc1216.
[RFC1217] V.G. Cerf, "Memo from the Consortium for Slow Commotion Research (CSCR)", RFC 1217, April 1, 1991, https://www.rfc-editor.org/rfc/rfc1217.
[RFC1437] A. Huitema, "The Extension of MIME Content-Types to a New Medium", RFC 1437, April 1, 1993, https://www.rfc-editor.org/rfc/rfc1437.
[RFC1438] C. Partridge, "Internet Engineering Task Force Statements of Boredom (SOBs)", RFC 1438, April 1, 1993, https://www.rfc-editor.org/rfc/rfc1438.
[RFC1605] C. Huitema, "SONET to Sonnet Translation", RFC 1605, April 1, 1994, https://www.rfc-editor.org/rfc/rfc1605.
[RFC1606] S. Greenfield, "A Historical Perspective on The Usage of IP Version 9", RFC 1606, April 1, 1994, https://www.rfc-editor.org/rfc/rfc1606.
[RFC1607] J. Haynes, "A VIEW FROM THE 21ST CENTURY", RFC 1607, April 1, 1994, https://www.rfc-editor.org/rfc/rfc1607.
[RFC1776] A. Phillips, "The Address is the Message", RFC 1776, April 1, 1995, https://www.rfc-editor.org/rfc/rfc1776.
[RFC1924] R. Elz, "A Compact Representation of IPv6 Addresses", RFC 1924, April 1, 1996, https://www.rfc-editor.org/rfc/rfc1924.
[RFC1925] R. Callon, "The Twelve Networking Truths", RFC 1925, April 1, 1996, https://www.rfc-editor.org/rfc/rfc1925.
[RFC1926] S. Bradner, "An Experimental Encapsulation of IP Datagrams on Top of ATM", RFC 1926, April 1, 1996, https://www.rfc-editor.org/rfc/rfc1926.
[RFC1927] M. Ohta, "Suggested Additional MIME Types for Associating Documents", RFC 1927, April 1, 1996, https://www.rfc-editor.org/rfc/rfc1927.
[RFC2100] A. Padlipsky, "The Naming of Hosts", RFC 2100, April 1, 1997, https://www.rfc-editor.org/rfc/rfc2100.
[RFC2321] D. Waitzman, "RITA -- The Reliable Internetwork Troubleshooting Agent", RFC 2321, April 1, 1998, https://www.rfc-editor.org/rfc/rfc2321.
[RFC2322 [RFC2322] K. van den Hout, "Management of IP numbers by peg-dhcp", RFC 2322, April 1, 1998, https://www.rfc-editor.org/rfc/rfc2322.
[RFC2323] M. Kennedy, "IETF Identification and Security Guidelines", RFC 2323, April 1, 1998, https://www.rfc-editor.org/rfc/rfc2323.
[RFC2324] L. Masinter, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, April 1, 1998, https://www.rfc-editor.org/rfc/rfc2324.
[RFC2325] B. Kaliski, "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", RFC 2325, April 1, 1998, https://www.rfc-editor.org/rfc/rfc2325.
[RFC2549] D. Waitzman, "IP over Avian Carriers with Quality of Service", RFC 2549, April 1, 1999, https://www.rfc-editor.org/rfc/rfc2549.
[RFC2550] P. Bressen, "Y10K and Beyond", RFC 2550, April 1, 1999, https://www.rfc-editor.org/rfc/rfc2550.
[RFC2551] A. Falk, "The Roman Standards Process -- Revision III", RFC 2551, April 1, 1999, https://www.rfc-editor.org/rfc/rfc2551.
[RFC2795] S. Christey, "The Infinite Monkey Protocol Suite (IMPS)", RFC 2795, April 1, 2000, https://www.rfc-editor.org/rfc/rfc2795.
[RFC3091] C. Droms, "Pi Digit Generation Protocol", RFC 3091, April 1, 2001, https://www.rfc-editor.org/rfc/rfc3091.
[RFC3092] M. Crawford, "Etymology of "Foo"", RFC 3092, April 1, 2001, https://www.rfc-editor.org/rfc/rfc3092.
[RFC3093] M. Gaynor, "Firewall Enhancement Protocol (FEP)", RFC 3093, April 1, 2001, https://www.rfc-editor.org/rfc/rfc3093.
[RFC3251] S. Bradner, "Electricity over IP", RFC 3251, April 1, 2002, https://www.rfc-editor.org/rfc/rfc3251.
[RFC3252] A. Barbir, "Binary Lexical Octet Ad-hoc Transport", RFC 3252, April 1, 2002, https://www.rfc-editor.org/rfc/rfc3252.
[RFC3514] S. Bellovin, "The Security Flag in the IPv4 Header", RFC 3514, April 1, 2003, https://www.rfc-editor.org/rfc/rfc3514.
[RFC3751] S. Hollenbeck, "Omniscience Protocol Requirements", RFC 3751, April 1, 2004, https://www.rfc-editor.org/rfc/rfc3751.
[RFC4041] S. Bradner, "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, April 1, 2005, https://www.rfc-editor.org/rfc/rfc4041.
[RFC4042] M. Crispin, "UTF-9 and UTF-18 Efficient Transformation Formats of Unicode", RFC 4042, April 1, 2005, https://www.rfc-editor.org/rfc/rfc4042.
[RFC4824] J. Wood, "The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)", RFC 4824, April 1, 2007, https://www.rfc-editor.org/rfc/rfc4824.
[RFC5241] A. Durand, "Naming Rights in IETF Protocols", RFC 5241, April 1, 2008, https://www.rfc-editor.org/rfc/rfc5241.
[RFC5242] A. Falk, "A Generalized Unified Character Code: Western European and CJK Sections", RFC 5242, April 1, 2008, https://www.rfc-editor.org/rfc/rfc5242.
[RFC5513] D. Farinacci, "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1, 2009, https://www.rfc-editor.org/rfc/rfc5513.
[RFC5514] J. Arkko, "IPv6 over Social Networks", RFC 5514, April 1, 2009, https://www.rfc-editor.org/rfc/rfc5514.
[RFC5841] R. Hay, "TCP Option to Denote Packet Mood", RFC 5841, April 1, 2010, https://www.rfc-editor.org/rfc/rfc5841.
[RFC5984] S. Krishnan, "Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding", RFC 5984, April 1, 2011, https://www.rfc-editor.org/rfc/rfc5984.
[RFC6214] A. Durand, "Adaptation of RFC 1149 for IPv6", RFC 6214, April 1, 2011, https://www.rfc-editor.org/rfc/rfc6214.
[RFC6217] G. Montenegro, "Regional Broadcast Using an Atmospheric Link Layer", RFC 6217, April 1, 2011, https://www.rfc-editor.org/rfc/rfc6217.
[RFC6592] S. Josefsson, "The Null Packet", RFC 6592, April 1, 2012, https://www.rfc-editor.org/rfc/rfc6592.
[RFC6758] B. Carpenter, "Media Type 'application/1d-interleaved-parityfec'", RFC 6758, April 1, 2013, https://www.rfc-editor.org/rfc/rfc6758.
[RFC6921] A. Durand, "Design Considerations for Faster-Than-Light (FTL) Communication", RFC 6921, April 1, 2013, https://www.rfc-editor.org/rfc/rfc6921.
[RFC7169] S. Moonesamy, "The NSA (No Secrecy Afforded) Certificate Extension", RFC 7169, April 1, 2014, https://www.rfc-editor.org/rfc/rfc7169.
[RFC7481] R. Hinden, "The Internationalization of April Fools' Day", RFC 7481, April 1, 2015, https://www.rfc-editor.org/rfc/rfc7481.
[RFC7511] J. Livingood, "Scenic Routing for IPv6", RFC 7511, April 1, 2015, https://www.rfc-editor.org/rfc/rfc7511.
[RFC8140] R. Hinden, "The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character", RFC 8140, April 1, 2017, https://www.rfc-editor.org/rfc/rfc8140.
[RFC8369] M. Thomson, "Internationalizing IPv6 Using 128-Bit Unicode", RFC 8369, April 1, 2018, https://www.rfc-editor.org/rfc/rfc8369.
[RFC8370] D. Harkins, "Modern Problems in Computing: An Encyclopædia of Essential RFCs", RFC 8370, April 1, 2018, https://www.rfc-editor.org/rfc/rfc8370.
[RFC8565] B. Carpenter, "Jabber Scribe Role for Conferences", RFC 8565, April 1, 2019, https://www.rfc-editor.org/rfc/rfc8565.
[RFC8566] B. Carpenter, "Requirements for the Conversion between Permanent Connections and Switched Connections in a General Switched Connection Network", RFC 8566, April 1, 2019, https://www.rfc-editor.org/rfc/rfc8566.
[RFC8752] D. Crocker, "Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)", RFC 8752, April 1, 2020, https://www.rfc-editor.org/rfc/rfc8752.
[RFC8962] R. Hinden, "ASCII Art in Internet-Drafts and RFCs", RFC 8962, April 1, 2021, https://www.rfc-editor.org/rfc/rfc8962.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
Copyright (c) 20233 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Adnan Masood
Los Pollos Hermanos
D Lazar
Los Pollos Hermanos
