communication

% Messaging and Communication

Drafted 2021-03-28 japhb

NOTE: This is a rumination on a problem space, not an active design.

What's Past is Prologue

Zawinski's Law tells us β€œEvery program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” Despite this observation being made decades ago, it still comes up regularly, because it still rings true.

MUGS, being a platform play from the get-go, won't even try to pretend this won't happen. While jwz wasn't just talking about messaging, it is one of the first ways MUGS is likely going to be expected to expand, if only to make it easier and more enjoyable for friends to play together. Better to embrace the inevitable now and see if we can avoid painting ourselves into a design corner.

Goals

A number of goals for any MUGS messaging system are clear, but also in partial conflict. Part of the design difficulty will be balancing these goals, though it is not necessary to choose just one point in the solution space. To satisfy the majority of the goals the majority of the time, it may be necessary to offer multiple modes of communication or some form of configurability. Nevertheless, here are some early goals:

Privacy : Players will want some assurance of privacy, at least that no one other than intended recipients will be able to read messages they send. This includes privacy from privileged users such as server and universe administrators, if at all possible.

Recording as a choice : At least one of the participants should have to choose to record a conversation for it to be recorded in a permanent or semi-permanent way; the default behavior should be that messages are ephemeral. In some jurisdictions, it may also be important that all participants are aware that someone is (or might be) recording the conversation.

Anti-harrasment : Essentially every form of communication has been used for harrasment. Messaging designs should try to reduce the ease with which harassers abuse the platform and its participants, and allow victims and community leaders to stop abusers when they do find a way to attack.

Time-shifting : Members of the MUGS community are likely to be on wildly different time schedules, necessitating at least some method of sending delayed messages, even if the participants are never logged into the same MUGS universe at the same instant.

Secure interoperability : It's nigh-inevitable that at some point there will be feature requests to interoperate with other messaging systems. Care should be taken to create interlinks in the most secure, privacy-preserving fashion possible, with full transparency about risks from the interoperation.

Encryption

Some of the above goals, such as privacy from privileged users, can only be achieved with strong end-to-end encryption. At the same time, it is a truism in the security field that one should never roll one's own encryption and trust it to actually be secure. This is true on several levels:

  • Don't design a new encryption or security algorithm.

  • Don't write a fresh implementation of an existing encryption or security algorithm.

  • Don't use an implementation or algorithm that hasn't been relentlessly attacked and battle tested.

  • Even when reusing a well-regarded implementation of a well-regarded security suite, don't assume surrounding application code won't undermine that security.

It's important that any encryption use be upgradeable (and protected from downgrade attacks); the state of the art changes rapidly enough that no single cryptosystem can be trusted long term.

Public, Semi-Public, Private

The scope of intended audience affects messaging design enough that different audiences may require different messaging paths. For example, these cases likely inhabit very different portions of the problem space:

  • Persistent messages to all players in a universe

  • A broadcast to everyone currently logged into a server

  • A game commentator discussing play-by-play in a tournament

  • A player inviting their friends to play together

  • A team leader directing team tactics

  • An out-of-game private chat with 2+ participants

To be precise, here are some of the differences:

SituationPersistentRead StatusPrivateExpires
Universe messagesYESYESnomaybe
Server broadcastnononono
Game commentatorYESnomaybeno
Friend invitesYESmaybeYESYES
Team tacticsnonoYESYES
Out-of-game chatmaybeYESYESmaybe

MUGS v0.1.4

Multi-User Gaming Services - A Raku-based platform for game service development

Authors

  • Geoffrey Broadwell

License

Artistic-2.0

Dependencies

MUGS::Core:ver<0.1.4>MUGS::Games:ver<0.1.4>MUGS::UI::CLI:ver<0.1.4>MUGS::UI::TUI:ver<0.1.4>MUGS::UI::WebSimple:ver<0.1.4>

Test Dependencies

Provides

  • MUGS

The Camelia image is copyright 2009 by Larry Wall. "Raku" is trademark of the Yet Another Society. All rights reserved.

Built with Podlite β€” the markup and publishing tools behind this site.