Algorithmic game theory (AGT) is an interdisciplinary field at the intersection of game theory and computer science, focused on understanding and designing algorithms for environments where multiple strategic agents interact. This research area combines computational thinking with economic principles to address challenges that emerge when algorithmic inputs come from self-interested participants. In traditional algorithm design, inputs are assumed to be fixed and reliable. However, in many real-world applications—such as online auctions, internet routing, digital advertising, and resource allocation systems—inputs are provided by multiple independent agents who may strategically misreport information to manipulate outcomes in their favor. AGT provides frameworks to analyze and design systems that remain effective despite such strategic behavior. The field can be approached from two complementary perspectives: Analysis: Evaluating existing algorithms and systems through game-theoretic tools to understand their strategic properties. This includes calculating and proving properties of Nash equilibria (stable states where no participant can benefit by changing only their own strategy), measuring price of anarchy (efficiency loss due to selfish behavior), and analyzing best-response dynamics (how systems evolve when players sequentially optimize their strategies). Design: Creating mechanisms and algorithms with both desirable computational properties and game-theoretic robustness. This sub-field, known as algorithmic mechanism design, develops systems that incentivize truthful behavior while maintaining computational efficiency. Algorithm designers in this domain must satisfy traditional algorithmic requirements (such as polynomial-time running time and good approximation ratio) while simultaneously addressing incentive constraints that ensure participants act according to the system's intended design. == History == === Nisan-Ronen: a new framework for studying algorithms === In 1999, the seminal paper of Noam Nisan and Amir Ronen drew the attention of the Theoretical Computer Science community to designing algorithms for selfish (strategic) users. As they claim in the abstract: We consider algorithmic problems in a distributed setting where the participants cannot be assumed to follow the algorithm but rather their own self-interest. As such participants, termed agents, are capable of manipulating the algorithm, the algorithm designer should ensure in advance that the agents’ interests are best served by behaving correctly. Following notions from the field of mechanism design, we suggest a framework for studying such algorithms. In this model the algorithmic solution is adorned with payments to the participants and is termed a mechanism. The payments should be carefully chosen as to motivate all participants to act as the algorithm designer wishes. We apply the standard tools of mechanism design to algorithmic problems and in particular to the shortest path problem. This paper coined the term algorithmic mechanism design and was recognized by the 2012 Gödel Prize committee as one of "three papers laying foundation of growth in Algorithmic Game Theory". === Price of Anarchy === The other two papers cited in the 2012 Gödel Prize for fundamental contributions to Algorithmic Game Theory introduced and developed the concept of "Price of Anarchy". In their 1999 paper "Worst-case Equilibria", Koutsoupias and Papadimitriou proposed a new measure of the degradation of system efficiency due to the selfish behavior of its agents: the ratio of between system efficiency at an optimal configuration, and its efficiency at the worst Nash equilibrium. (The term "Price of Anarchy" only appeared a couple of years later.) === The Internet as a catalyst === The Internet created a new economy—both as a foundation for exchange and commerce, and in its own right. The computational nature of the Internet allowed for the use of computational tools in this new emerging economy. On the other hand, the Internet itself is the outcome of actions of many. This was new to the classic, ‘top-down’ approach to computation that held till then. Thus, game theory is a natural way to view the Internet and interactions within it, both human and mechanical. Game theory studies equilibria (such as the Nash equilibrium). An equilibrium is generally defined as a state in which no player has an incentive to change their strategy. Equilibria are found in several fields related to the Internet, for instance financial interactions and communication load-balancing. Game theory provides tools to analyze equilibria, and a common approach is then to ‘find the game’—that is, to formalize specific Internet interactions as a game, and to derive the associated equilibria. Rephrasing problems in terms of games allows the analysis of Internet-based interactions and the construction of mechanisms to meet specified demands. If equilibria can be shown to exist, a further question must be answered: can an equilibrium be found, and in reasonable time? This leads to the analysis of algorithms for finding equilibria. Of special importance is the complexity class PPAD, which includes many problems in algorithmic game theory. == Areas of research == === Algorithmic mechanism design === Mechanism design is the subarea of economics that deals with optimization under incentive constraints. Algorithmic mechanism design considers the optimization of economic systems under computational efficiency requirements. Typical objectives studied include revenue maximization and social welfare maximization. === Inefficiency of equilibria === The concepts of price of anarchy and price of stability were introduced to capture the loss in performance of a system due to the selfish behavior of its participants. The price of anarchy captures the worst-case performance of the system at equilibrium relative to the optimal performance possible. The price of stability, on the other hand, captures the relative performance of the best equilibrium of the system. These concepts are counterparts to the notion of approximation ratio in algorithm design. === Complexity of finding equilibria === The existence of an equilibrium in a game is typically established using non-constructive fixed point theorems. There are no efficient algorithms known for computing Nash equilibria. The problem is complete for the complexity class PPAD even in 2-player games. In contrast, correlated equilibria can be computed efficiently using linear programming, as well as learned via no-regret strategies. === Computational social choice === Computational social choice studies computational aspects of social choice, the aggregation of individual agents' preferences. Examples include algorithms and computational complexity of voting rules and coalition formation. Other topics include: Algorithms for computing Market equilibria Fair division Multi-agent systems And the area counts with diverse practical applications: Sponsored search auctions Spectrum auctions Cryptocurrencies Prediction markets Reputation systems Sharing economy Matching markets such as kidney exchange and school choice Crowdsourcing and peer grading Economics of the cloud == Journals and newsletters == ACM Transactions on Economics and Computation (TEAC) SIGEcom Exchanges Algorithmic Game Theory papers are often also published in Game Theory journals such as GEB, Economics journals such as Econometrica, and Computer Science journals such as SICOMP.
Sanctuary (app)
Sanctuary is a mobile app focusing on astrology and mystical services. Users enter their birthday, time of birth, and place of birth information into the app and receive a birth chart as well as daily horoscope readings. Users can also sign up for a monthly membership and receive on-demand astrological readings via a text message format. The service has been described as being “Talkspace for astrology" and "Uber for astrological readings". The mobile app uses an A.I.-driven interface. On May 14, 2019, Apple featured Sanctuary as the App of the Day. == History == Sanctuary initially began as project within the incubator of Lorne Michaels’ Broadway Video Ventures. The app officially launched on March 21, 2019. Its backers include Broadway Video Ventures, Greycroft Partners, and Shari Redstone.
Simply Local
Simply Local is a decentralized community social networking and neighborhood broadcasting service developed by Simply Local, based in New Delhi. The app is used as a tool by residents to bridge the information gap and know what is happening in the locality. Simply Local creates private geo-fenced networks for people living in an area and provides social and community related services within that network. The user doesn’t post to a single person but broadcasts to a chosen community. One of its primary purposes is also to connect citizens to their elected representatives. Each community is independent of the other and information shared remains telescoped to that particular community. The app has been designed to maintain privacy and security of users and provides decentralized social networking in the sense that it forms an owner-independent, micro community, which is not connected with the world outside. Simply Local is available on Android Play and iOS App Store. It is available in two languages - English and Hindi. Simply Local’s founder and CEO is Nikhil Bapna. == History == 2020 May: Included as a Top 5 Useful App by Zee News. 2020: Used to connect candidates with local residents during the Delhi assembly elections. 2019: Renamed from Gadfly to its current name. 2018: Used for Karnataka State Elections to get detailed information on candidates. 2017: Launched under the name Gadfly as a tool to connect citizens with their elected representatives.
Server-Gated Cryptography
Server-Gated Cryptography (SGC), also known as International Step-Up by Netscape, is a defunct mechanism that was used to step up from 40-bit or 56-bit to 128-bit cipher suites with SSL. It was created in response to United States federal legislation on the export of strong cryptography in the 1990s. The legislation had limited encryption to weak algorithms and shorter key lengths in software exported outside of the United States of America. When the legislation added an exception for financial transactions, SGC was created as an extension to SSL with the certificates being restricted to financial organisations. In 1999, this list was expanded to include online merchants, healthcare organizations, and insurance companies. This legislation changed in January 2000, resulting in vendors no longer shipping export-grade browsers and SGC certificates becoming available without restriction. Internet Explorer supported SGC starting with patched versions of Internet Explorer 3. SGC became obsolete when Internet Explorer 5.01 SP1 and Internet Explorer 5.5 started supporting strong encryption without the need for a separate high encryption pack (except on Windows 2000, which needs its own high encryption pack that was included in Service Pack 2 and later). "Export-grade" browsers are unusable on the modern Web due to many servers disabling export cipher suites. Additionally, these browsers are incapable of using SHA-2 family signature hash algorithms like SHA-256. Certification authorities are trying to phase out the new issuance of certificates with the older SHA-1 signature hash algorithm. The continuing use of SGC facilitates the use of obsolete, insecure Web browsers with HTTPS. However, while certificates that use the SHA-1 signature hash algorithm remain available, some certificate authorities continue to issue SGC certificates (often charging a premium for them) although they are obsolete. The reason certificate authorities can charge a premium for SGC certificates is that browsers only allowed a limited number of roots to support SGC. When an SSL handshake takes place, the software (e.g. a web browser) would list the ciphers that it supports. Although the weaker exported browsers would only include weaker ciphers in its initial SSL handshake, the browser also contained stronger cryptography algorithms. There are two protocols involved to activate them. Netscape Communicator 4 used International Step-Up, which used the now obsolete insecure renegotiation to change to a stronger cipher suite. Microsoft used SGC, which sends a new Client Hello message listing the stronger cipher suites on the same connection after the certificate is determined to be SGC capable, and also supported Netscape Step-Up for compatibility (though this support in the NT 4.0 SP6 and IE 5.01 version had a bug where changing MAC algorithms during Step-Up did not work properly).
Social media therapy
Social media therapy is a form of expressive therapy. It uses the act of creating and sharing user-generated content as a way of connecting with and understanding people. Social media therapy combines different expressive therapy aspects of talk therapy, art therapy, writing therapy, and drama therapy and applies them to the web domain. Within social media therapy, synchronous or asynchronous dialogue occurs through exchanges of audio, text or visual information. The digital content is published online to serve as a form of therapy. == Background == Time spent online via email, websites, instant messaging and social media has increased: since 1999, more than 2,554 million people have become internet users. This alters the way people communicate with each other, and alters the connotation of certain words. The concepts of "identity", "friend", "like" and "connected" have adapted alongside technology. People are influenced by data sharing, social marketing, and technological tools. There are multiple therapeutic services offered through the internet. E-therapy, online counseling, cyber therapy, and social media therapy are similar in that each utilizes the internet in order to provide therapy for patients. == Controversy == There are pros and cons when it comes to the subject of online therapy. Criticism of providing therapy through online methods comes from concerns over the lack of physical contact. There are important features of therapy created through face-to-face therapy such as transference and countertransference that can not be created through online therapy. Patricia R. Recupero and Samara E. Rainey stated in their article "Informed Consent to E-Therapy" of American Journal of Psychotherapy that the lack of face-to-face interaction increased the risk of misdiagnosis and misunderstanding between the E-therapist and patient, thereby increasing the risk of uncertainty for the clinician. There are also concerns over the internet creating a distraction from the therapy itself. Confidentiality and privacy concerns have been raised as well. However, several systematic reviews have found that online psychotherapy can produce clinical outcomes comparable to face-to-face treatment, suggesting that physical distance does not inherently reduce therapeutic effectiveness.
Syman
SYMAN is an artificial intelligence technology that uses data from social media profiles to identify trends in the job market. SYMAN is designed to organize actionable data for products and services including recruiting, human capital management, CRM, and marketing. SYMAN was developed with a $21 million series B financing round secured by Identified, which was led by VantagePoint Capital Partners and Capricorn Investment Group.
Chunked transfer encoding
Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. At any given time, no knowledge of the data stream outside the currently-being-processed chunk is necessary for either the sender or the receiver. Each chunk is preceded by its size in bytes and transmission ends when a zero-length chunk is received. The chunked keyword in the Transfer-Encoding header is used to indicate chunked transfer. Chunked transfer encoding is not supported in HTTP/2, which provides its own mechanisms for data streaming. == Rationale == The introduction of chunked encoding provided various benefits: Chunked transfer encoding allows a server to maintain an HTTP persistent connection for dynamically generated content. In this case, the HTTP Content-Length header cannot be used to delimit the content and the next HTTP request/response, as the content size is not yet known. Chunked encoding has the benefit that it is not necessary to generate the full content before writing the header, as it allows streaming of content as chunks and explicitly signaling the end of the content, making the connection available for the next HTTP request/response. Chunked encoding allows the sender to send additional header fields after the message body. This is important in cases where values of a field cannot be known until the content has been produced, such as when the content of the message must be digitally signed. Without chunked encoding, the sender would have to buffer the content until it was complete in order to calculate a field value and send it before the content. == Applicability == For version 1.1 of the HTTP protocol, the chunked transfer mechanism is considered to be always and anyway acceptable, even if not listed in the Transfer-Encoding (TE) request header field, and when used with other transfer mechanisms, should always be applied last to the transferred data and never more than one time. This transfer encoding method also allows additional entity header fields to be sent after the last chunk if the client specified the "trailers" parameter as an argument of the TE request field. The origin server of the response can also decide to send additional entity trailers even if the client did not specify the "trailers" parameter, but only if the metadata is optional (i.e. the client can use the received entity without them). Whenever the trailers are used, the server should list their names in the Trailer header field; three header field types are specifically prohibited from appearing as a trailer field: Content-Length, Trailer, and Transfer-Encoding. == Format == If a Transfer-Encoding field with a value of "chunked" is specified in an HTTP message (either a request sent by a client or the response from the server), the body of the message consists of one or more chunks and one terminating chunk with an optional trailer before the final ␍␊ sequence (i.e. carriage return followed by line feed). Each chunk starts with the number of octets of the data it embeds expressed as a hexadecimal number in ASCII followed by optional parameters (chunk extension) and a terminating ␍␊ sequence, followed by the chunk data. The chunk is terminated by ␍␊. If chunk extensions are provided, the chunk size is terminated by a semicolon and followed by the parameters, each also delimited by semicolons. Each parameter is encoded as an extension name followed by an optional equal sign and value. These parameters could be used for a running message digest or digital signature, or to indicate an estimated transfer progress, for instance. The terminating chunk is a special chunk of zero length. It may contain a trailer, which consists of a (possibly empty) sequence of entity header fields. Normally, such header fields would be sent in the message's header; however, it may be more efficient to determine them after processing the entire message entity. In that case, it is useful to send those headers in the trailer. Header fields that regulate the use of trailers are Transfer-Encoding with the "trailers" parameter (used in requests) and Trailer (used in responses). == Use with compression == HTTP servers often use compression to optimize transmission, for example with Content-Encoding: gzip or Content-Encoding: deflate. If both compression and chunked encoding are enabled, then the content stream is first compressed, then chunked; so the chunk encoding itself is not compressed, and the data in each chunk is compressed holistically (i.e. based on the whole content). The remote endpoint then decodes the stream by concatenating the chunks and uncompressing the result. == Example == === Encoded data === The following example contains three chunks of size 4, 7, and 11 (hexadecimal "B") octets of data. 4␍␊Wiki␍␊7␍␊pedia i␍␊B␍␊n ␍␊chunks.␍␊0␍␊␍␊ Below is an annotated version of the encoded data. 4␍␊ (chunk size is four octets) Wiki (four octets of data) ␍␊ (end of chunk) 7␍␊ (chunk size is seven octets) pedia i (seven octets of data) ␍␊ (end of chunk) B␍␊ (chunk size is eleven octets) n ␍␊chunks. (eleven octets of data) ␍␊ (end of chunk) 0␍␊ (chunk size is zero octets, no more chunks) ␍␊ (end of final chunk with zero data octets) Note: Each chunk's size excludes the two ␍␊ bytes that terminate the data of each chunk. === Decoded data === Decoding the above example produces the following octets: Wikipedia in ␍␊chunks. The bytes above are typically displayed as Wikipedia in chunks.