68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
New era of BBS-Style "Carracho"
Posted by: ProfDrLuigi on 2026-09-27 00:47:23
Carracho is a new ("old") native macOS client and server platform for communities built around chat, files, news, messaging and self-hosted servers. A ton of modern new features. 🙂

The project takes the ideas that made Carracho distinctive and rebuilds them as a modern application: a single place for persistent server bookmarks, live chat rooms, threaded discussions, file exchange, private conversations, tracker discovery and full server administration.

The macOS client is written in Swift/AppKit and targets macOS 10.15 or newer. A matching server/tracker/bot implementation is included for macOS, together with a native headless C server and tracker for Linux.

Strong authenticated encryption​

Connections between the new Carracho client and a modern Carracho server use a new authenticated transport designed for confidentiality and tamper detection. Control traffic and transfer-port operations are protected with AES-256-GCM, with fresh session key material negotiated through ephemeral X25519 key agreement.

The modern transport protects far more than login traffic: chat/control packets, file transfers, News transfers, file search, banners and other modern transfer operations all use authenticated encrypted framing. The client also shows the negotiated cipher in the server information panel, so a modern connection can be identified as AES-256-GCM rather than the historical transport.

Compatibility with original Carracho software is intentionally treated as a bridge, not as the definition of the new project.

The practical side effect of keeping the protocol lineage intact is useful:

  • the new macOS client can connect to many original/Classic Carracho servers;
  • the modern server can accept original Carracho clients when authenticationMode is legacyCompatible;
  • Classic trackers, files, chat, user administration and other reconstructed protocol areas remain available;
  • when a Classic peer is detected, modern-only capabilities are hidden or mapped to the older behaviour automatically;
  • a server can optionally expose a separate legacyFilesRoot to Classic clients while modern clients continue to use the primary filesRoot.
Classic connections use the historical transport and the limits of the historical protocol. Features invented for the new platform, such as modern authenticated transport, threaded-News extensions, reactions, rich-media capability negotiation, offline-message extensions and new account permissions, require a modern Carracho peer.

Servers can also be configured as modernOnly. In that mode the compatibility password material required by original clients is not retained, so Classic authentication is deliberately unavailable.


You can Download it here: GitHub​



An Admin Webinterface is available too.
1790495125127.png1790495138395.png1790495147174.png
Posted by: adespoton on 2026-09-27 11:21:53
Nice! The only concern I have is that if someone connects to the modern server with a modern client, they may expect all their activity to stay secure in transport, where if compatibility mode is enabled, that data might be leaking through another classic client’s activity.
Does the modern client indicate when the server it’s connecting to has compatibility mode enabled, and identity classic clients when they connect?
Posted by: ProfDrLuigi on 2026-09-27 12:25:56
Where your concern is valid is server fan-out. If a modern user posts something that a Classic client is legitimately supposed to receive, the server sends a separate copy to that Classic session using the legacy transport. For example:

  • a message in a chat room containing a Classic user,
  • a private message sent directly to a Classic user,
  • presence/user information that Classic clients normally receive.
It does not mean a Classic client suddenly receives unrelated modern-to-modern PMs or arbitrary modern traffic. The server chooses recipients first, then encodes/transports the data appropriately for each recipient. Still, the confidentiality of a shared message is only as strong as the weakest recipient connection.

By the way ... the legacy connection could have it`s own file folder. This way they have no access to the Folder where the Modern Clients have access and vice versa.
1790537223300.png

For those admins who won`t this legacy feature at all there is an option to disable it completely so no classic client can connect. They have the choice.


1790536949084.png


EDIT:
the next Update will include an info string if legacy is enabled or disabled on the server.

1790539177470.png

EDIT 2:
And you can detect legacy users by it`s status. This is "burned in" and can`t be manipulated by the user.
1790539547785.png
Posted by: ProfDrLuigi on 2026-09-27 14:09:51
Update 1.1.1 is out ....
1