Carracho 1.1.7

Carracho 1.1.7

Carracho Client 1.1.7 (build 18) brings improved user context menus, personal Ignore controls, bookmark organization, more reliable reconnection and accurate read status. It also consolidates the existing multi-bookmark stability improvements into this release. Carracho Server remains 1.1.6 (build 17); Classic/Legacy packet layouts are unchanged.

Highlights

• Edit a connected user's account directly from the user-list context menu as an authorized administrator, without visiting Accounts first.
• Use the same context menu in the conference participant list, with actions bound to the actual clicked user.
• Ignore or unignore users without administrator privileges; hide their private messages and conference messages, and suppress new-message notifications and unread counts.
• See ignored users with a strikethrough nickname in the regular and conference user lists.
• Switch immediately from a stalled/offline server bookmark to another connected server without leaving the previous server's empty workspace on screen.
• Restore the correct status and control state when selecting an existing server connection, and prevent late callbacks from one server affecting another.
• Correct the German/English localization of the new context-menu actions.
• Fixed a multi-bookmark reconnect bug that could leave one bookmark selected while its underlying client reconnected with another bookmark's host and login, causing data such as the Files view to come from the wrong server.
• Auto-reconnect state is now isolated per saved bookmark instead of sharing one global retry identity.
• Connected background bookmarks with auto-reconnect enabled now retry independently after an unexpected disconnect.
• Preserved each bookmark's last valid session snapshot across connection loss so switching bookmarks during a reconnect cannot replace one server's UI state with another server's state.
• Hardened background reconnect handling for server agreements and boot-scoped Message Center history.
• Kept the server header at a fixed height across bookmarks so the center workspace no longer jumps vertically when optional banner or server-detail rows appear or disappear.
• News threads and Message Center conversations are now marked read automatically when their content is actually opened or becomes visible again, including already-selected items that received new content while another workspace was active.
• Saved server bookmarks can now be reordered directly in the sidebar by dragging their server icon; the custom order is persisted across launches without changing bookmark identities or connection state.
• Updated the macOS Client to 1.1.7 / build 18; Carracho Server remains 1.1.6 / build 17.

Carracho Client 1.1.7

Same user context menu in conferences

Both the main server user list and each conference's participant list now offer the same right-click menu. Depending on connection state and permissions, it provides Info, Message, Ignore User / Stop Ignoring, Edit User Account…, Kick and Ban. The own-user Sleep action remains available where applicable.

Conference actions are attached to the exact clicked user ID, rather than relying on a potentially unrelated selection in the main user list. Sorting the participant list therefore does not redirect a menu action to another user.

Admin account editing directly from user lists

The Edit User Account… action is available only to authorized administrators. It resolves the selected live user's login and opens the existing account editor, with the usual server-side permission checks. On modern servers, the client automatically requests account groups and membership if the Accounts page has not been opened yet. On Classic servers, the existing Classic account editor is used. The account must expose an editable login.

This fixes the error that previously appeared on the first direct edit attempt until the administrator visited Accounts to initialize the groups.

Ignore users without administrator privileges

Any user can choose Ignore User on someone else. New private messages and conference chat from ignored users are hidden locally, and their unread counts and notifications are suppressed. Existing conversations are retained and return after Stop Ignoring. This is a local display/notification preference, not a kick or a server-side ban:

• New private messages and conference chat entries from that user are not shown or saved to the local conversation/transcript during the ignore.
• Existing private conversations are hidden rather than deleted. They become visible again after Stop Ignoring.
• Ignored conversations no longer contribute new-message notifications or unread badges, including when other connected bookmarks are running in the background.
• In the normal user list and the conference participant list, the ignored user's nickname is struck through, preserving its existing name color. Both lists refresh as soon as the setting changes.
• Users cannot ignore their own account through this action.

Recognizable ignored users

Ignored users have a struck-through nickname in both the main user list and every conference participant list. The indication updates immediately when Ignore or Stop Ignoring is selected, and the original nickname color is retained. Messages that were hidden are shown again if the ignore is removed.

Safe ignore persistence

For modern peers with stable account UUIDs, an ignore is saved per server endpoint and local login, persists across application restarts and follows that account's identity. On older/Classic peers that provide only reusable numeric session IDs, the ignore applies only to the current connection to avoid mistakenly silencing someone else after a reconnect. If a stable identity becomes available during the session, the ignore can be promoted to that identity.

Instant bookmark switching during connection failures

Switching away from an offline server while its TCP connection is still pending no longer leaves the previous bookmark's empty workspace visible. The destination bookmark becomes active immediately, including an already-established session on another server.

• The new bookmark's own session snapshot, workspace data, status label and Connect/Disconnect control are restored together.
• The shared presentation is cleared before loading a different bookmark's state, avoiding stale Files or Overview content.
• Connection callbacks are tied to the originating client. A timeout or login result that arrives later for the old bookmark cannot replace the selected server's UI.
• A connecting bookmark can continue its own connection attempt in the background. A server agreement is never accepted on the user's behalf.

This addresses the case where a failed Zeb's connection left an empty Files/Overview panel displayed even after selecting the already-connected Admin bookmark.

Correct session status and asynchronous callbacks

Returning to an already-connected server bookmark refreshes its connection status and Connect/Disconnect controls immediately. Background connection attempts are kept on their original client and their delayed success, failure or timeout callbacks cannot repaint another selected server's view.

German and English user actions

The English and German Localizable.strings resources now correctly parse the new context-menu entries. In German, the actions are Benutzerkonto bearbeiten…, Ignorieren and Ignorieren aufheben. The issue was a malformed newline sequence in the resource file, not missing translations.

Multi-bookmark reconnect isolation

Reconnect ownership is now tied to the bookmark and LegacyControlClient that actually lost its connection. A stale reconnect marker from a previously selected bookmark can no longer win over the active connection and reconnect that client using another bookmark's host, login or password.

This fixes the failure mode where the sidebar could still show one bookmark as connected while workspaces such as Files were actually displaying data from a different server after sleep/wake or another transient disconnect.

Independent background auto-reconnect

Each saved bookmark now maintains its own reconnect timer and retry backoff. If several bookmarks are connected and one of the background connections drops, that bookmark can reconnect independently when Auto-Reconnect is enabled instead of relying on the single foreground retry state.

When a foreground reconnect is already pending and the user switches to another bookmark, the pending retry is transferred to that bookmark's background context without losing its retry state. Merely selecting a bookmark that was never connected does not cause it to start connecting in the background.

Session snapshot safety during reconnects

An unexpected disconnect now preserves the bookmark's last valid session snapshot before the shared presentation is reset. Switching away while a reconnect is pending therefore keeps Files, News, users, channels and related per-server presentation state associated with the correct bookmark.

Once a background reconnect succeeds, server information, the root directory, channels and News groups are refreshed against that bookmark's own client before its snapshot is reused.

Reorder saved bookmarks

Saved server bookmarks in the Bookmarks sidebar section can now be reordered by dragging the server icon on the left side of a bookmark row.

The new order is stored through the existing bookmark persistence layer and restored on the next launch. Reordering only changes presentation order: bookmark UUIDs, Keychain passwords, selected bookmark identity, live connection contexts, unread state and reconnect state remain attached to the same bookmark.

Automatic read state when content is opened

News and Message Center now treat actually viewi...

Carracho 1.1.6

Carracho 1.1.6

Carracho 1.1.6 focuses on more durable messaging, clearer unread indicators, and a redesigned macOS Server service model. The macOS Client and Server are version 1.1.6 (build 17) for this release, with the native Linux Server using the same Server version metadata.

Highlights

• Message Center history for the selected bookmark is now available immediately after launching the client, even before reconnecting to the server.
• Added an optional Dock badge showing the total number of unread private messages, including unread conversations on connected background bookmarks.
• Added a News sidebar badge showing the total number of unread threaded News posts.
• Reworked the macOS Server and Tracker into independent launchd system services backed by a compact shared headless daemon binary instead of copying a second complete Server app into the daemon directory.
• Server and Tracker installation, removal, start/stop and automatic startup are now controlled exclusively from their always-visible System Service sections.
• The macOS Server app now detects when an installed daemon differs from the daemon embedded in the updated app and offers Update Now on every app launch until the service binary is refreshed.
• Hardened Linux source synchronization so native rebuilds receive the shared version/release metadata and fail before stopping the live service when required source files are missing.
• Updated Carracho and Carracho Server version reporting to 1.1.6 / build 17.

Carracho Client 1.1.6

Message Center history while offline

The selected server bookmark now restores its persisted Message Center history as soon as the client starts, without requiring a successful connection first. Stable account-UUID conversations are restored directly from the bookmark's server/account scope.

For peers that still rely on the boot-scoped fallback introduced in 1.1.5, Carracho can display the most recently observed server-boot history while disconnected. A real connection still revalidates the server boot before a numeric session identity is trusted for new routing or persistence.

Switching to a saved bookmark while disconnected also loads that bookmark's locally persisted Message Center history, making previous conversations useful even when the remote server is unavailable.

Unread private-message Dock badge

Carracho can now show the total number of unread private messages directly on its Dock icon. The count includes the active server as well as connected background bookmarks, and unread state is only cleared when the relevant conversation is actually visible in the active key window.

The feature is enabled by default and can be switched off under Settings → General → App Behavior → Show unread private messages on the Dock icon. Disabling it clears the Dock badge immediately.

Unread News sidebar badge

The main News sidebar item now shows the total number of unread threaded News posts using the same red badge presentation as the other unread counters in the client.

The count comes from the existing per-server/per-account News read state, updates during background News polling, decreases as individual threads are actually read, and is restored correctly when switching back to a connected bookmark session. Merely opening the News workspace does not clear unread posts.

Carracho Server 1.1.6

Dedicated Server and Tracker system services

The macOS Server and Tracker can now run as two independent launchd system services. Both jobs use the same compact carracho-serverd helper embedded in the Server app, while Server and Tracker retain separate launchd jobs and separate running/automatic-start state.

Installing a service copies only the headless daemon binary and the service definitions required to run it. The daemon directory no longer needs a second complete copy of Carracho Server.app, avoiding duplicated application bundles under /Applications and the service installation.

The helper is built as a Universal 2 binary and contains the headless Server/Tracker runtime rather than the AppKit administration UI or Sparkle updater.

System Service is the single control surface

Server and Tracker runtime control is now consolidated under the always-visible System Service section for each component. The old duplicate Start/Stop controls in the page header, application menu and status menu have been removed.

Each service can be installed or uninstalled independently, started or stopped independently, and configured independently for automatic startup with macOS. Current running state and startup-at-boot state are separate: disabling automatic startup does not stop a service that is already running.

The System Service section is permanently expanded and no longer has a disclosure arrow, so installation and runtime controls remain visible without another layer of navigation.

Daemon update reminder after an app update

The Server app now compares the daemon helper embedded in the current app with the binary installed for the system services. The comparison is byte-for-byte, so rebuilt hotfixes are detected even if their marketing version happens to be unchanged.

When an installed daemon differs from the helper in the updated app, Reinstall changes to Update Now. On every normal launch of the Server app, a warning explains that the application was updated and the system service must also be refreshed. The warning continues to appear until the installed daemon matches the current app.

Choosing Update Now performs the same privileged service refresh used by the System Service controls while preserving the installed sibling service's running and automatic-start state. Because Server and Tracker share the daemon binary, updating either installed service refreshes the common executable.

Release tooling

Safer Linux source synchronization

The Xcode Sync Server target now transfers the shared scripts directory together with Version-Server.xcconfig and Release.xcconfig into /opt/carracho/sources. Native Linux builds therefore receive the version loader and metadata required by the split Client/Server version configuration.

compile.sh now validates all required synchronized source files before stopping the live service. An incomplete source upload fails immediately with a clear error instead of taking the running Carracho Server offline and only then discovering missing build metadata.

Release packaging for the headless macOS daemon

The macOS Server release publisher now validates and signs the embedded carracho-serverd helper together with the application bundle. The packaged Server app therefore contains the exact helper used by the System Service installer and daemon-update comparison.

Compatibility notes

• Classic/Legacy protocol packet layouts remain unchanged in 1.1.6.
• Message Center offline restoration remains scoped by server/account identity; numeric fallback history is still limited to the most recently known server-boot namespace.
• The Dock badge is a client preference and does not change server behavior or private-message persistence.
• Threaded News unread badges require the modern threaded-News query support already used by the 1.1.5 News read-state system.
• macOS Server and Tracker remain independently controllable launchd jobs even though they share one installed carracho-serverd executable.
• After updating the macOS Server app, an already installed system service should be updated from System Service → Update Now before relying on the new daemon code.
• Client, macOS Server and native Linux Server are all 1.1.6 / build 17 in this release.

Carracho 1.1.5

Carracho 1.1.5

Carracho 1.1.5 focuses on Message Center persistence, large Files directories, faster Finder-style preview access, and cleaner independent Client/Server versioning. The macOS Client and Server are version 1.1.5 (build 16) for this release, with the native Linux Server using the same Server version metadata.

Highlights

• Fixed Private Message history disappearing after restarting the Carracho client in several identity and multi-bookmark cases introduced around the stable-account migration.
• Added a safe boot-scoped persistence fallback when a server does not provide a stable peer account UUID, covering original/Classic servers and older modern Carracho servers without allowing recycled numeric user IDs to cross a server restart.
• Private Messages, edits and reactions received on connected background bookmarks are now persisted immediately in the correct server/account scope.
• Added an optional Confirm disconnection client setting for manual disconnects.
• Fixed large modern directory listings by transferring them in bounded pages instead of exceeding the legacy 65,535-byte TLV value limit.
• Added Finder-style Quick View from the Files list: pressing the Space bar on a selected previewable file opens the existing preview window.
• Split Client and Server version metadata into independent configuration files while retaining a separate shared GitHub release version.
• Release changelog generation now refreshes an existing version block deterministically instead of leaving stale generated content behind.
• Updated Carracho and Carracho Server version reporting to 1.1.5 / build 16.

Carracho Client 1.1.5

Private-message history survives app restarts

When a Private Message conversation receives its stable account UUID after messages have already arrived, Carracho now persists the complete promoted conversation history rather than only the conversation metadata. Messages collected before identity promotion therefore survive quitting and restarting the app.

The promotion path merges any already restored UUID-backed history with the temporary session conversation before writing it, so a late identity update no longer discards either side of the conversation.

Boot-scoped fallback when a peer UUID is unavailable

Servers predating stable peer identity, including original/Classic servers and older modern Carracho builds, can still provide only a numeric session user ID. Carracho now persists those conversations inside a separate namespace tied to the current server boot.

The client resolves that namespace from server uptime. Restarting only Carracho restores the same history; restarting the server creates a new namespace, so a recycled numeric user ID cannot inherit another user's messages. If a stable account UUID becomes available later, the boot-scoped history is merged into the UUID-backed conversation and the temporary record is retired only after the durable UUID history has been written successfully.

Background bookmark Message Center persistence

Private Messages received while another bookmark remains connected in the background are now applied directly to that bookmark's Message Center snapshot and persisted in that bookmark's own server/account scope. Message edits and reactions are persisted there as well.

Quitting Carracho therefore no longer loses background-server Message Center activity merely because that bookmark had not been activated again before the app exited.

Optional disconnect confirmation

A new Confirm disconnection option is available under Carracho Settings → General → App Behavior. When enabled, manually disconnecting from an active server requires confirmation before the connection is closed.

Cancelling a pending automatic reconnect and internal protocol-driven disconnects remain immediate, so the confirmation is limited to the deliberate manual action it is meant to guard.

Large directory listings

Modern Carracho connections now page directory listings that would exceed the legacy 65,535-byte size of a single TLV value. The client requests successive pages automatically and merges them before presenting the folder, so directories with thousands of files no longer fail to open when their packed listing crosses the historical wire-size limit.

The paging is transparent to the Files UI and preserves entry order, Finder labels and existing directory metadata.

Space bar opens Quick View

When a single previewable file is selected in the Files list, pressing the Space bar now opens the same Quick View window as the toolbar button and context-menu command.

The shortcut follows the existing Quick View availability rules and does not override normal table behavior for folders, unsupported files, multiple selections or otherwise unavailable previews.

Carracho Server 1.1.5

Paged directory replies for modern clients

The Swift/macOS Server and native Linux Server now support modern directory-list paging. Each page stays below the legacy UInt16 TLV-value limit and includes a continuation offset when more entries remain.

Paging is requested explicitly by modern clients. Clients that do not request it continue to receive the historical single-listing response, leaving Classic packet layouts unchanged.

Shared support for boot-scoped client history

No new durable identity is invented for old peers that cannot provide one. Instead, the client uses the existing server-uptime information to scope numeric user IDs to one server process lifetime. Current servers continue to provide stable account UUID metadata to modern clients as introduced in 1.1.4.

This keeps the 1.1.5 fallback compatible with original/older servers while preserving the 1.1.4 protection against history being rebound after a server restart.

Release tooling

Independent Client and Server version metadata

Client and Server versions now have separate configuration sources. Version-Client.xcconfig controls the macOS Client, while Version-Server.xcconfig controls the macOS Server, native Linux Server and Debian packages.

Release.xcconfig separately defines the shared GitHub release/tag version. Client and Server can therefore carry different product versions in future while still publishing their ZIP assets into one shared release when desired. Runtime version strings and native Linux build metadata derive from these configured versions rather than duplicated literals in Swift or C source.

Refreshable generated changelog blocks

The release renderer now replaces an existing generated version block when rerun instead of assuming that every version is new. This keeps the rolling Client and Server changelogs synchronized with the current release notes during release preparation and republishing.

Compatibility notes

• Classic/Legacy packet layouts remain unchanged.
• Large-directory paging requires a paging-capable modern client and server. Older servers retain their historical single-TLV directory-size limit.
• Servers without stable peer UUID metadata use the boot-scoped Message Center fallback. A real server restart intentionally starts a fresh numeric-ID history namespace.
• Current 1.1.5 servers continue to provide stable account UUID metadata to modern clients, which remains the preferred durable Message Center identity.
• Pre-1.1.4 session-ID-only Message Center rows are still not automatically imported because their original account ownership cannot be proven safely.
• Client and Server version sources are now independent even though both products are 1.1.5 / build 16 in this release.

Carracho 1.1.4

Carracho 1.1.4

Carracho 1.1.4 focuses on keeping Message Center private conversations tied to the correct account across reconnects and server restarts. The macOS client and server are version 1.1.4 (build 15), and the stable peer-identity extension is implemented by both the Swift/macOS and native Linux servers.

Highlights

• Fixed a Message Center history bug where a recycled transient server user ID could make an older private conversation appear under a different user after a server restart.
• Private Message history is now keyed by the server account's stable UUID instead of the temporary numeric session user ID.
• The Swift/macOS and native Linux servers now send stable account identity metadata to modern clients while leaving Classic packet layouts unchanged.
• Added a new v2 local Message Center history schema that keeps durable conversations separated by stable account identity.
• Older session-ID-based private-message history is deliberately not imported automatically because its ownership cannot be proven safely after IDs have been recycled.
• Improved Sparkle republishing so metadata for an existing build is regenerated from the replacement Universal 2 archive instead of retaining stale hardware requirements.
• Updated Carracho and Carracho Server version reporting to 1.1.4 / build 15.

Carracho Client 1.1.4

Stable Message Center conversation identity

Private conversations in Message Center no longer use the server's transient numeric userID as their durable identity. Modern servers now provide the authenticated account UUID for each visible user, and Carracho stores and selects conversations by that stable account identity while keeping the numeric user ID only as the current live routing address.

This fixes the case where a server restart reused a numeric user ID for a different account. Previously, the stored conversation for that number could be relabelled with the new user's nickname and avatar, making messages from one account appear inside another account's conversation. In 1.1.4, a conversation can only reconnect to the exact same account UUID.

The live mapping is also hardened against incomplete disconnects: a durable conversation with an account UUID can never be rebound merely because a later session happens to reuse the same numeric user ID.

Safer local private-message history

Message Center now stores durable Private Message conversations in a v2 SQLite schema keyed by stable peer account UUID. Older session-ID-based private-message history is deliberately not imported automatically because its account ownership cannot be proven safely after IDs have been recycled; those old rows are left untouched in the local database but ignored by the new history. Message edits, reactions, drafts, unread state, avatars, transport metadata and the existing 500-message per-conversation limit continue to use the same Message Center behavior.

Offline Messages use their separate account-aware storage and are not affected by this private-conversation history change.

Safe fallback for older servers

If a server does not provide a stable account UUID, Carracho still allows Private Messages during the current connection, but that conversation remains session-only instead of being persisted under an identity that cannot be trusted across reconnects.

This keeps communication compatible with older servers without recreating the history-mixing bug.

Carracho Server 1.1.4

Stable account identity for modern peer metadata

Both the Swift/macOS server and the native Linux server now include the authenticated account UUID in modern user-arrival and user-update metadata. The stable identifier is sent in initial user snapshots, new-user events and later user metadata refreshes so modern clients can distinguish account identity from the temporary numeric session user ID. Modern observers also receive the stable account identity for Classic peers, while Classic recipients continue to receive the historical packet layouts unchanged.

This identity metadata does not change Private Message routing or grant access to another user's messages. Messages are still routed to the current live session; the UUID is used by modern clients to associate local history with the correct authenticated account.

Release tooling

Safer Sparkle appcast republishing

Republishing an existing build number now removes the old item from the copied appcast before Sparkle regenerates the feed entry. This forces Sparkle to infer system and hardware metadata from the replacement archive instead of carrying forward stale metadata from an earlier artifact.

The publishing scripts also verify that a Universal 2 release does not retain an arm64-only hardware requirement before accepting the generated appcast.

Compatibility notes

• The new stable account-identity field is sent only to modern clients; Classic/Legacy packet layouts are unchanged.
• The 1.1.4 macOS and native Linux servers both provide stable peer account identities to modern clients.
• Against older servers that do not provide a stable account UUID, Private Message conversations remain usable for the current session but are not persisted as durable history.
• Pre-1.1.4 private Message Center history keyed by transient session user IDs is not automatically imported into the v2 history because its account ownership cannot be verified safely. Existing old rows are left untouched on disk.
• Offline Messages are unaffected by the private-conversation storage migration.

Carracho 1.1.3

Carracho 1.1.3

Carracho 1.1.3 focuses on safer first-run server setup, more capable Files operations, and configurable macOS window-close behaviour. The macOS client and server are version 1.1.3 (build 14), with matching first-run support in the native Linux server and installers.

Highlights

• Files can now delete multiple selected server items in one operation.
• The Upload dialog can select multiple local files and folders at once and queue them together.
• Added a client setting controlling whether closing the last window quits Carracho or leaves it running in the Dock.
• Fresh server databases now protect the built-in admin account with a random initial password before the server can accept connections.
• First-run setup clearly explains that anonymous has no password by default and can be given one in Administration → Accounts.
• Linux installation documentation now explicitly requires the server runtime user to have full access to /opt/carracho and its contents.
• Updated Carracho and Carracho Server version reporting to 1.1.3 / build 14.

Carracho Client 1.1.3

Multi-select Files operations

The Files browser now applies Delete to all selected server items when the account has the required delete permissions for every selected file or folder. A single confirmation covers the batch, delete requests are sent safely one after another, and selecting both a folder and one of its children does not generate a redundant second delete for that child.

Successful deletions are removed from the visible file tree immediately. Individual failures are reported without discarding successful operations from the same batch.

The Upload dialog now allows selecting multiple local files and/or folders at once. Every selected item is added to the existing transfer queue, and transfer capacity is refreshed once for the complete batch. Multi-item Finder drag-and-drop uses the same batched enqueue path.

Configurable red close-button behaviour

The General client settings now include an App Behavior option controlling what happens when the last Carracho window is closed with the red macOS close button.

The option defaults to enabled, preserving the historical behaviour: closing the final window quits Carracho. When disabled, the window closes but Carracho remains running in the Dock and existing server sessions remain active. Clicking the Carracho Dock icon brings the main window back. Quit Carracho from the application menu still terminates the app normally.

Carracho Server 1.1.3

Secure first-run administrator credentials

A genuinely new server database no longer leaves the built-in admin account with an empty password until an administrator changes it manually. Before the server runtime can accept connections, Carracho generates a random 128-bit initial password and applies it to the built-in admin account.

On macOS, the Server app displays the generated password once in an Initial Server Credentials warning and provides a Copy Password action. On Linux source installs and fresh Debian package installs, the installer prints the initial administrator login and password before the service is started. In both cases the administrator is explicitly told to change the password immediately after the first login.

The generated plaintext password is not written to a separate credentials file. Existing databases and migrated legacy state are not assigned a new password by this bootstrap logic.

Anonymous first-run notice

The built-in anonymous Guest account intentionally remains passwordless by default. The first-run notice now states this explicitly and explains that an administrator can set a password for anonymous under Administration → Accounts when passwordless Guest access is not desired.

Linux runtime permissions

The Linux installation instructions now explicitly state that the user configured to run carracho-server must have full read, write, create/remove, and directory-traversal access to the complete /opt/carracho tree.

With the standard service this user is carracho, so /opt/carracho should remain owned appropriately by carracho:carracho. Installations using a different systemd User= or Group= must adjust ownership and permissions accordingly. The documentation explicitly discourages making /opt/carracho world-writable.

Compatibility notes

• Multi-delete and multi-upload are client-side improvements and do not require a new file protocol.
• Existing server databases are not modified by the new first-run password bootstrap.
• anonymous remains passwordless unless an administrator explicitly assigns a password.

Carracho 1.1.2

Carracho 1.1.2

Carracho 1.1.2 focuses on Private Message interaction, clearer unread state, tighter Guest restrictions, and Linux server packaging. The macOS client and server are version 1.1.2 (build 13), with matching protocol support in the native Linux server.

Highlights

• Added reactions to modern Private Messages using the same reaction set as News.
• Guest accounts can no longer send offline messages; the restriction is enforced in the client and on both server implementations.
• Removed the visible address/IP column from Tracker result tables.
• Added red unread badges with white counts for Conference messages, Private Messages, and Offline Messages.
• Added a client preference for hiding user sign-in/sign-out notifications.
• Linux server builds and installers now include the bundled Bot avatar under etc/ and preserve customized avatars across upgrades.
• Updated Carracho and Carracho Server version reporting to 1.1.2 / build 13.

Carracho Client 1.1.2

Private Message reactions

Modern Private Messages now support reactions directly in Message Center. Each reactable message exposes a ☺ React action with the same reaction set used by News: 👍, ❤️, 😂, 🎉, 😮, and 😢.

Each participant can keep one reaction per message, replace it with another reaction, or remove it. Reaction changes are delivered live between two connected modern clients. The local user's reaction and the peer's reaction are stored separately in messages.sqlite3, so the state remains visible after reopening the client.

Reaction-capable Private Messages use a shared message UUID on the wire, including messages with media attachments. Existing five-minute edit rules remain unchanged and still apply only to eligible text messages. Previously stored Private Messages are intentionally not retrofitted with reactions because their old locally generated UUIDs were never shared with the peer.

Classic Private Messages remain unchanged and never receive reaction capability or reaction packets.

Guest offline-message restriction

Guest accounts can still receive and read offline messages, but they can no longer send them. The modern client hides Send Offline Messages completely for Guests and closes an already-open offline-message composer if the active account is changed to Guest while connected.

The restriction is also enforced by both the Swift/macOS and native Linux servers. Guest requests for the offline-message recipient list or for sending an offline message are rejected server-side, so older or modified clients cannot bypass the client UI restriction.

Account Holders and Administrators retain the existing offline-message functionality.

Cleaner Tracker server list

The Tracker result table no longer shows the server address/IP column. Endpoints remain available internally for connecting to the selected server, while the visible list focuses on server name, user count, description, and the remaining Tracker metadata.

Unread badges in the sidebar

Conference messages, Private Messages, and Offline Messages now use compact red badges with white counts in the sidebar, matching the existing bookmark notification style.

For Conferences, an expanded section shows the unread badge on the affected room. When the Conferences section is collapsed, the combined unread total moves to the Conferences row. Counts above 99 are displayed as 99+.

Optional sign-in/sign-out notifications

The General client settings now include Show user sign-in and sign-out notifications under Server Messages.

The option defaults to enabled so existing behaviour is preserved. When disabled, visual notifications announcing that a user entered or left a server are suppressed. Presence tracking and the user list remain active, and separately configured sign-in/sign-out sounds continue to work.

Carracho Server 1.1.2

Private Message reaction routing

The Swift/macOS and native Linux servers advertise the modern Private Message reaction capability and relay reaction changes between connected modern peers. The server does not persist Private Message history or reaction state; that remains client-side.

Classic sessions are excluded from the reaction extension and keep the historical Private Message protocol unchanged.

Guest offline-message enforcement

Both server implementations now reject Guest requests to obtain the offline-message recipient list or send an offline message. Guests can still receive and read offline messages.

Linux Bot avatar packaging

Native Linux builds now stage carracho-bot-avatar.png together with the server and Bot configuration under etc/.

Fresh source installs deploy the bundled 128 × 128 PNG to:

/opt/carracho/etc/carracho-bot-avatar.png

Source-based upgrades preserve an existing live Bot avatar instead of replacing an administrator-selected image with the bundled default. Debian server packages also include the PNG and register it as a configuration file so normal package upgrades preserve local customization.

Version reporting

macOS and Linux server version reporting now identifies the release as Carracho Server 1.1.2. The Bot RSS user agent is updated to Carracho-Bot-RSS/1.1.2 on both server implementations.

Compatibility notes

• Private Message reactions require a current modern server and modern clients on both ends.
• Classic Private Messages are unchanged.
• Guest offline-message sending is intentionally blocked server-side, including for older clients.
• Existing Message Center databases are migrated in place for reaction metadata.
• Existing customized Linux Bot avatars are preserved during supported source/package upgrades.

Carracho 1.1.1

Carracho 1.1.1

Carracho 1.1.1 improves transparency around Classic/Legacy compatibility. Modern users can now immediately see whether the connected server allows Classic clients, and Classic users are clearly identified in the modern user list.

The Swift/macOS and native Linux servers expose the same compatibility state to modern clients while preserving the historical Server Info layout for Classic clients.

Highlights

• Added a visible Legacy Mode = On / Off line below the connected server description.
• The value reflects the server's actual authentication/compatibility configuration.
• Both the Swift/macOS and native Linux servers expose the same modern Server Info capability.
• Classic clients continue to receive the historical Server Info field set unchanged.
• When an Administrator changes the authentication mode, the local server header updates immediately.
• Classic/Legacy users are now shown with the fixed status text @ Legacy in the modern user list.
• Modern user status messages remain unchanged.
• Updated Carracho and Carracho Server version reporting to 1.1.1 / build 12.

Carracho Client 1.1.1

Visible Legacy Mode state

The connected-server header now contains a third line below the server description:

Legacy Mode = On

or:

Legacy Mode = Off

Legacy Mode = On means that the server is configured to allow Classic/Legacy clients in addition to modern clients.

Legacy Mode = Off means that Classic/Legacy connections are disabled.

The client does not infer this state from the currently connected users. It reads the value directly from the server's advertised compatibility configuration.

Older modern servers that do not provide the new capability simply omit the Legacy Mode line rather than displaying an assumed value.

When an Administrator changes the authentication mode from Advanced Administration, the displayed Legacy Mode state is refreshed immediately after the setting is saved.

Clear Classic-user identification

Classic/Legacy clients cannot publish the modern per-user status message used by current Carracho clients.

The modern user list therefore uses that otherwise unused status row to display:

@ Legacy

for users connected through the Classic/Legacy transport.

This leaves normal modern status messages untouched while making it immediately visible which users are connected through the historical protocol.

Carracho Server 1.1.1

Public compatibility state for modern clients

The modern Server Info reply now includes the public boolean capability:

legacyCompatibilityEnabled

using modern Server Info field:

0xf0000106

The value is taken directly from the server configuration:

• Swift/macOS: the configured authentication mode;
• native Linux: the server's legacy_compatible state.

This allows a modern client to distinguish between its own secure modern transport and the separate server policy that determines whether Classic clients may also connect.

Classic compatibility preserved

The new compatibility field is sent only to modern sessions.

Classic clients continue to receive the historical Server Info fields only, preserving compatibility with original clients that do not safely skip modern extension fields.

macOS and Linux parity

Both server implementations expose the same Legacy compatibility state to modern clients:

• Swift/macOS Server;
• native Linux Server.

The native Linux Server Info reply and HTTP status version reporting now identify the server as Carracho Server 1.1.1.

The Bot RSS user agent has likewise been updated to Carracho-Bot-RSS/1.1.1 on both server implementations.

Compatibility

Carracho 1.1.1 does not change the historical Classic protocol.

• The new Legacy Mode capability is a modern Server Info extension.
• Classic clients do not receive the new field.
• Older modern servers can still be used; the 1.1.1 client simply hides the Legacy Mode line when the capability is unavailable.
• The @ Legacy marker is a client-side presentation feature and does not modify Classic user data.
• Modern users retain their normal status-message behavior.

For the complete Legacy Mode visibility feature, use a Carracho 1.1.1 client with a matching Carracho Server 1.1.1.

Carracho 1.1.0

Carracho 1.1.0

Carracho 1.1.0 adds a complete optional moderation workflow for Guest uploads. Servers can keep completed Guest uploads outside the published Files tree until an Administrator explicitly approves or rejects them, while Account Holder and Administrator uploads continue to publish normally.

The feature is implemented consistently by the Swift/macOS and native Linux servers, including persistent pending state, remote administration, destination-name reservation, and explicit uploader feedback in the modern client.

Highlights

• Optional Guest uploads require approval policy.
• Dedicated Pending Guest Uploads queue in Administration.
• Pending rows show destination, uploader, size, and upload time.
• Administrators can Approve, Reject, and Refresh pending uploads.
• Connected Administrator bookmarks show 🚨 while one or more Guest uploads are awaiting approval.
• Completed Guest payloads remain hidden in a persistent .carracho-pending area until moderation is complete.
• Pending uploads are excluded from normal Files listings, downloads, filename search, and Bot File Watchers.
• The intended final destination stays reserved while an upload is pending.
• Approval publishes without overwriting an existing destination.
• Modern Guest clients receive an explicit awaiting approval notice after the server has accepted the complete upload.
• Folder uploads receive that notice only once, after the entire folder tree and all contained file data have been received and verified.
• Pending upload state survives server restarts on both macOS and Linux.
• The policy is available through modern server settings and the HTTP Administration settings API.
• Classic/Legacy Guest uploaders remain compatible because moderation is enforced server-side.

Carracho Client 1.1.0

Guest upload moderation in Administration

Administration now includes Guest Upload Approval under Advanced.

The new Guest uploads require approval option is disabled by default. When enabled, completed uploads from Guest accounts are placed into the server's pending queue instead of being published immediately.

Administrators can review pending uploads with the following information:

• destination path;
• uploader;
• size;
• upload time.

The queue provides Approve, Reject, and Refresh actions.

Bookmark approval alert

A connected Administrator bookmark displays 🚨 whenever that server has one or more Guest uploads awaiting approval. The state is maintained per bookmark, so a background-connected server can raise the alert without being the currently active server.

The server pushes queue-count changes to connected modern Administrators when a new pending upload is created or an item is approved/rejected. On connection or reconnection, the client also loads the existing pending queue so already-waiting uploads are not missed. The alert disappears automatically after the final pending upload has been resolved.

Approval and rejection use stable pending-upload identifiers rather than exposing internal server filesystem paths to the client.

When connected to an older modern server that does not expose Guest upload approval, the client leaves the moderation controls unavailable while keeping the rest of Administration usable.

Clear feedback for Guest uploaders

A modern Guest client now receives a dedicated notice after a moderated upload has been fully accepted into the server's approval queue.

For a file upload, the client explains that the upload completed successfully but will become visible only after an Administrator approves it.

For a folder upload, Carracho waits until the entire folder transfer has completed. The notice is sent only once, after all subfolders and contained files have been received and verified. Individual files inside the folder do not generate separate approval notices.

This keeps the distinction clear between:

• the transfer finishing successfully; and
• the uploaded item becoming publicly visible in Files.

Carracho Server 1.1.0

Server-side Guest upload approval

Both server implementations support the persistent setting:

guestUploadApprovalEnabled

It defaults to false for existing configurations.

When the setting is enabled, Guest uploads continue to use the normal .carracho transfer-staging path while data is arriving. After the complete upload has been validated, the payload is moved into a hidden .carracho-pending area instead of being published under its intended final name.

Before approval, a pending payload is:

• absent from normal Files listings;
• unavailable through normal download paths;
• excluded from the filename search index;
• ignored by Bot File Watchers.

Account Holder and Administrator uploads are unaffected and continue to publish immediately.

Complete folder handling

Folder uploads are moderated as one complete upload tree.

The server receives and verifies every transfer entry first, including all nested files and subfolders. Only after the complete tree has passed the final transfer checks is the root folder accepted into the pending area.

The uploader notification is emitted after that point, so a partial or interrupted folder upload cannot be reported as awaiting approval.

Safe publication and rejection

While an item is pending, its intended final destination remains reserved. A second upload cannot silently claim the same destination name before moderation is resolved.

Approve publishes the pending payload using no-overwrite semantics. Once publication succeeds, the normal filename search index is updated and the final filesystem event becomes visible to Bot File Watchers.

Reject permanently removes the hidden pending payload.

The pending manifest is persisted and survives server restarts.

macOS and Linux parity

The Guest upload approval workflow is implemented in both:

• the Swift/macOS server runtime;
• the native Linux server runtime.

Both implementations apply the same core behavior for staging, destination reservation, approval, rejection, persistence, search visibility, and uploader notification.

Remote configuration

The approval policy is exposed through the normal modern Carracho server-settings protocol.

The native Linux HTTP Administration API also exposes:

guestUploadApprovalEnabled

through:

GET /api/v1/settings
PATCH /api/v1/settings

The HTTP settings API controls the policy itself. Pending-upload Approve and Reject actions remain Carracho Administration operations and are not exposed as HTTP moderation endpoints.

Compatibility

Carracho 1.1.0 keeps the historical transfer protocol compatible while adding modern moderation controls.

• Guest upload approval is a server-side policy.
• Classic/Legacy Guest clients can therefore still upload normally and can still be subject to approval.
• The explicit awaiting approval uploader notice is a modern asynchronous extension and is not sent to Classic/Legacy clients.
• Approval and rejection require modern Administrator support.
• Older modern servers may omit the Guest upload approval setting; the 1.1.0 client handles that case without breaking the rest of Administration.
• Account Holder and Administrator uploads retain their existing immediate-publication behavior.

For the complete 1.1.0 workflow, use a Carracho 1.1.0 client with a matching Carracho Server 1.1.0.

Carracho 1.0.9

Carracho 1.0.9

Carracho 1.0.9 is a focused performance, presentation, and server-behavior release. It makes large server-wide Files searches substantially lighter to scroll, keeps Conference message identity intact after users disconnect, refreshes Tracker and macOS Server artwork, and gives administrators explicit control over whether Bot File Watcher announcements are visible to Guest accounts.

The Swift/macOS and native Linux servers continue to share the same modern File Watcher behavior while preserving Classic/Legacy protocol compatibility.

Highlights

• Significantly smoother scrolling for large server-wide Files search result sets.
• More robust processing of very large search streams without deep callback recursion.
• Conference history keeps the sender's nickname, avatar, and group color after disconnect.
• Saved Tracker entries now use the dedicated Carracho Tracker artwork.
• Refreshed Carracho Server for macOS application icon.
• Bot File Watchers ignore internal .carracho transfer-staging paths.
• File Watcher announcements remain restricted to Account Holder and Administrator members by default.
• The Guest-delivery policy is persistent and implemented on both macOS and native Linux, including the HTTP Administration API.

Carracho Client 1.0.9

Faster large Files searches

Large server-wide search results have been reworked to avoid doing expensive work every time AppKit asks for a visible table cell.

Search results now use lightweight reusable cells rather than constructing the richer normal Files-browser hierarchy for every row entering the viewport.

The client also avoids repeatedly recomputing data while scrolling:

• the sorted search result set is kept as a stable snashot;
• formatted file sizes are cached;
• formatted modification dates are cached;
• file-kind text is cached by extension where possible;
• bundled file-type artworb is cached;
• LaunchServices is queried only for the actual final file extension instead of every dotted suffix in a filename.

This substantially reduces allocation, layout, sorting, and icon-resolution overhead for result sets containing thousands of files.

More robust search-result streaming

The legacy-compatible file-search reader can receive multiple records from bytes that are already buffered by NWConnection.

Previously, immediately reading the next record from inside the completion callback could build a very deep callback chain on sufficiently large result sets.

Carracho 1.0.9 schedules the next buffered record, and Classic keepalive processing, back onto the serial search queue before continuing. This lets the current callback unwind completely and prevents large searches from exhausting the worker thread's stack.

No search protocol change is required for this improvement.

Conference history keeps sender identity

Conference transcript rows no longer depend entirely on the current online-user table.

When a message is received, Carracho retains the sender information needed to render that historical row. Before a user is removed after disconnect, any older rows that still depend on the live user record are frozen as well.

As a result, previous Conference messages continue to show the sender's:

• nickname;
• avatar;
• group color.

This avoids old rows turning into Unknown User or losing their original presentation merely because the sender went offline.

Tracker presentation

Saved Tracker rows now use the dedicated Carracho Trackers artwork instead of the previous generic system network symbol.

The collapsible Tracker section header remains focused on disclosure state, while the actual Tracker entries carry the service-specific icon.

File Watcher Guest visibility

Administration now exposes a dedicated setting under Advanced → Bot File Watchers:

Show announcements to Guests

The default remains off. With the setting disabled, File Watcher messages are sent only to Account Holder and Administrator members of the selected Conference.

When enabled, Guest members in that Conference receive the same File Watcher announcement.

The setting is loaded and saved through the normal modern server-settings protocol.

For compatibility with older modern servers, the client treats the field as optional. If a connected server does not expose it, the File Watcher Guest control is disabled and the rest of the Advanced settings page continues to work normally.

Carracho Server 1.0.9

Cleaner File Watcher events

Bot File Watchers now ignore Carracho's internal transfer-staging paths on both server implementations.

Names matching the internal .carracho staging forms are excluded from recursive scans and filesystem-event processing. Descendants of staging directories are ignored as well.

This prevents a normal upload from producing announcements for temporary transfer artifacts before the final file or folder is in place.

The behavior is implemented in:

• the Swift/macOS filesystem watcher;
• the native Linux inotify watcher.

Persistence and remote administration

Remote Carracho Administration uses a modern server-setting field for the same value.

The HTTP Administration API also exposes the boolean through:

GET /api/v1/settings
PATCH /api/v1/settings

This keeps GUI administration, protocol administration, startup configuration, and HTTP administration aligned.

macOS Server artwork

Carracho Server for macOS now uses refreshed application icon artwork and an updated asset-catalog representation for the Server app.

Compatibility

Carracho 1.0.9 continues to preserve Classic/Legacy behavior.

• The Files-search performance changes are client-side implementation improvements and do not alter the search protocol.
• Conference identity snapshots affect only local transcript rendering.
• Older modern servers may omit the new field; the 1.0.9 client handles that case without making the rest of Advanced Administration unavailable.
• Classic/Legacy clients do not need to understand the new setting.

For the complete 1.0.9 feature set, use a Carracho 1.0.9 client with a matching Carracho Server 1.0.9.

Carracho 1.0.8

Carracho 1.0.8

Carracho 1.0.8 adds message editing for modern clients and servers, introduces configurable Bot File Watchers, improves direct navigation from Bot announcements into the Files browser, and removes duplicate Bot greeting controls from the macOS Server application.

Both the Swift/macOS server and the native Linux server implement the new modern protocol features while keeping Classic/Legacy protocol behavior unchanged.

Highlights

• Edit your own Conference and Private Messages for up to five minutes after sending.
• Edited messages are marked in the client and Private Message edit state is preserved locally.
• New Bot File Watchers can announce newly created files and folders in a selected Conference.
• File Watcher templates support {folder} and {file} placeholders.
• Use . as the watched path to monitor the complete server Files root.
• Bot folder links can be opened directly in the client's Files browser.
• File Watcher administration is available through the Carracho client and the HTTP Administration API.
• The macOS and native Linux server implementations support the same File Watcher and message-editing protocol extensions.
• Updated the macOS application icon and expanded English/German localization.
• Removed the duplicate Automatic Greeting editor from the macOS Server window.

Carracho Client 1.0.8

Message editing

Messages sent to a modern Carracho Server can now be edited for up to five minutes after sending.

Editing is available for:

• your own Conference messages;
• your own Private Messages in Message Center.

The client shows an Edit action while a message is still inside the edit window and marks changed messages as Edited afterwards.

Private Message edit metadata is stored in the local Message Center database, so the edited state remains visible with the rest of the local conversation history.

Message editing is intentionally limited to normal text messages. Messages containing image or other media references are not editable.

Classic/Legacy connections continue to use the original protocol and do not receive modern edit metadata or edit events.

Bot File Watcher administration

The Bot administration panel now includes a dedicated File Watcher section.

Administrators can configure multiple watchers with:

• enable/disable state;
• a folder below the server Files root;
• a target Conference;
• a custom announcement template.

Watcher paths are relative to the normal server Files root.

For example:

Incoming
Incoming/Uploads

To watch the Files root itself, use:

.

Announcement templates support:

{folder}
{file}

{folder} inserts a clickable link to the affected folder.

{file} inserts the detected file or folder name.

Example:

New {file} in {folder}

A File Watcher folder link can be clicked directly in Conference Chat. The client switches to Files and opens the corresponding server folder.

Interface and compatibility

• Added File Watcher controls to remote Bot administration.
• Added capability detection so unsupported servers do not expose unavailable File Watcher actions.
• Added direct handling for carracho-file:/// links.
• Updated the application icon artwork.
• Expanded English and German localization for File Watchers and message editing.

Carracho Server 1.0.8

Server-side message editing

The modern server protocol now supports message identifiers, server timestamps, edit capability negotiation, and edit events.

The server enforces the edit rules rather than relying on the client's clock.

An editable message must:

• belong to the user requesting the edit;
• still be inside the five-minute edit window;
• be a modern text message;
• contain no media attachment references.

Conference edits are propagated to modern members of the Conference.

Private Message edits are propagated to the modern participants in the conversation.

Classic/Legacy clients never receive modern edit packets, so their historical protocol layout and behavior remain unchanged.

The feature is implemented in both:

• the Swift/macOS Carracho Server runtime;
• the native Linux/C server runtime.

Bot File Watchers

Carracho Server now supports persistent Bot File Watchers.

A watcher monitors a configured directory below the normal Files root and can post an announcement to a selected Conference when new files or folders appear.

Watcher configuration includes:

• unique watcher ID;
• enable/disable state;
• relative watched path;
• target Conference;
• announcement template.

Up to 32 File Watchers can be configured.

Use . as the path to monitor the Files root itself.

Watcher paths are validated so they cannot escape the configured Files root.

File Watcher announcements

File Watchers support two template variables:

{folder}
{file}

{folder} becomes a clickable carracho-file:/// link pointing to the affected folder.

{file} becomes the name of the detected file or folder.

Example:

New {file} in {folder}

Filesystem event bursts are coalesced before posting, and repeated announcements for the same watcher/folder are rate-limited.

Hidden filesystem entries are ignored.

macOS implementation

The Swift/macOS server uses native filesystem event sources and recursively tracks configured watcher directories.

Watcher configuration is reloaded while the server is running, so changes made through Administration do not require restarting the server.

Native Linux implementation

The native Linux server includes the matching File Watcher implementation using inotify.

It supports:

• recursive directory monitoring;
• new file and folder detection;
• configuration reloads;
• debounce/coalescing;
• announcement cooldowns;
• the same {folder} / {file} template behavior as the macOS server.

Remote administration and HTTP API

File Watchers can be managed through the modern Carracho administration protocol.

The HTTP Administration API also exposes File Watcher configuration:

GET /api/v1/bot/file-watchers
PUT /api/v1/bot/file-watchers

The server validates watcher IDs, paths, target Conferences, templates, and watcher-count limits before saving the configuration.

macOS Server interface cleanup

The duplicate Automatic Greeting editor has been removed from the macOS Server window.

Bot greetings remain fully supported. They are now configured centrally from:

Carracho Client → Administration → Bot

The underlying greeting configuration remains part of the Bot configuration and is preserved when other Bot settings are changed.

Compatibility

Carracho 1.0.8 continues to preserve Classic/Legacy compatibility.

The new features are modern protocol extensions:

• message editing is negotiated as a modern capability;
• edit packets are not sent to Classic clients;
• File Watcher administration requires a modern server;
• the existing Classic chat, Private Message, file and Conference packet formats are not changed.

For the complete 1.0.8 feature set, use a Carracho 1.0.8 client with a matching Carracho Server 1.0.8.