messaging refers to one user sending another user a message (memo, letter, txt, photo …) that they read sometime later; on the IndieWeb, either directly via a personal site, or from one site to another. There are numerous technologies for such personal messaging.
Messaging is one part of building IndieWeb-centric communication.
Existing electronic messaging technologies and networks.
Email uses technologies such as:
Email typically allows anyone that knows your email address to send you a message, which has resulted in a poisoning of the technology, anywhere from spam, to vendor "donotreply@" messages, to badly written emails to mailing lists.
For this reason, many have abandoned email for day-to-day critical personal messaging and instead use one of the other solutions: iMessage, FB Messenger, DM, or even SMS. See below.
Private messaging. PM is a term for sending people private messages in IRC.
- XMPP / Jabber
SMS AKA txting requires the sender to know the receiver's cell phone number. Anyone that knows your mobile/cell number can send you a text message from their cell phone.
MMS is used for sending media such as photos in otherwise "text" messages.
Direct messaging. Invented by Twitter, direct messaging uses Twitter's site and typically clients (though there is also an SMS interface) to send messages which can then be received on a Twitter client, as well as optionally in email or by SMS, or both.
iMessage is Apple's proprietary messaging network where iOS devices (iPhone, iPad, iPod touch) and Macs with Messsages App installed can send messages to each other similar to SMS or MMS messages.
On iOS, "Messages" *is* the SMS application, and if both sender and recipient are registered with apple (e.g. their iPhone phone numbers, or AppleID email address), then the devices attempt to route the messages directly via Apple's servers, rather than the phone/SMS network.
Some people opt for a github issue queue instead of email. Unlike the git repo and the wiki feature on github, the only way to get data out of issues is programmatically through the API and from the copy delivered to participants in the issue thread.
Some in the indieweb community are brainstorming how to best do messaging from one indieweb presence to another. See the indieweb-messaging page for more.
Even while using other methods of communication, is it possible to use someone's IndieWeb site in the process of authenticating them to make sure they are who you think they are?
From an "indieweb" perspective, I find this transition from email to other forms of communication both interesting, and perhaps useful for clues as to where/how indieweb communication should work - that is, *why* are people migrating from email (supposedly open, federated, etc.) to other solutions which are seemingly more friendly, more usable, faster / lower latency, less noisy, quicker, etc.
I think there is unexplored promise in this use-case: sign-in-use-cases#messaging
And perhaps we also have an opportunity to define what "friending" on the indieweb means - perhaps it means two people have agreed to let each other send indieweb personal messages back/forth.
(and like bret says, I have zero desire to figure out / implement SMTP or IMAP or POP on my own server.) we can do better with web technologies and how modern messaging solutions have raised the bar in terms of UI/UX (compared to email).
- Tantek 20:29, 22 August 2013 (PDT)
- "It says something about the proprietary mess that is modern messaging apps that a single tech company has 3 incompatible messaging networks and making them compatible with each other is newsworthy. https://www.nytimes.com/2019/01/25/technology/facebook-instagram-whatsapp-messenger.html" @kylerankin January 25, 2019
- an example of a message sent in public as a reply https://timbl.com/timbl/Public/2019/04/02/for-ap.html
- "See you at Oktane? Pinged you on gitter. timbl"
- Use-case to be careful of when designing: Forwarding, in particular authenticating/verifying (and securing) both the forwarder and forwarding, but also transitively the senders and message(s) being forwarded. See https://chat.indieweb.org/social/2020-08-12/1597238678066600 for an example of how this is non-obvious and requires explicit design
- "* This question exposes a flaw in the current implementations of AP: there is no mechanism to allow forwarded messages to be verified. In email, DKIM can be used to guarantee that forwarded messages are authentic; no such capability exists in AP, and http-signatures can only be used to insure that the forwarder is valid, and cannot insure the forwarded message is valid." [ @BradKoehn[m]] August 12, 2020
- Be aware of abuse: https://twitter.com/boop/status/1138495199330689024
- "if your app has DMs, it’s a dating app, its the law" @boop June 11, 2019
- 2021-08-25 Ars Technica: A decade and a half of instability: The history of Google messaging apps / Sixteen years after the launch of Google Talk, Google messaging is still a mess.