* Add sendStory method for posting file attachment stories to My Story
Adds Manager.sendStory(attachment, allowsReplies), which uploads a file
attachment, builds a SignalServiceStoryMessage, and sends it to all
registered, non-blocked, non-hidden contacts that haven't opted out of
seeing the user's story (Contact.hideStory), excluding self. SendHelper
gains sendStoryMessage(), which resolves recipient addresses and
unidentified access and delegates to
SignalServiceMessageSender.sendGroupStory() against
DistributionId.MY_STORY, following the same address/access resolution
pattern used for group sends. A sync transcript is sent afterwards via
sendStorySyncMessage() so linked devices see the story was posted.
This is core library plumbing only; no CLI command, stub
implementations, or documentation are added yet.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MR2KF56Qcf9qNH1URj3XWs
* Add sendStory command for posting stories via CLI and JSON-RPC
Implements SendStoryCommand to allow users to post stories through the
CLI and JSON-RPC interfaces. Command accepts an attachment file path
(required) and optional --no-replies flag to disable replies on the story.
Handles AttachmentInvalidException and IOException appropriately and
outputs results using SendMessageResultUtils.
Registered in Commands.java in alphabetical order.
* Add sendStory stubs to DbusManagerImpl and StubManager
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MR2KF56Qcf9qNH1URj3XWs
* Document sendStory in man page and changelog
* Validate story attachment MIME type and fix D-Bus stub
- Reject non-image/video attachments before uploading, since stories
only support image and video content
- Change DbusManagerImpl.sendStory to throw UnsupportedOperationException
to match the pattern used by all other unimplemented D-Bus methods
* Resolve recipients before uploading story attachment
Move recipient resolution ahead of the attachment upload so that an
empty contact list is caught early without wasting bandwidth on an
upload that would reach nobody.
* Address review feedback: fix hideStory filter and remove redundant sync
- Fix hideStory filter to require contact exists (!=null &&) instead of
permitting null contacts (==null ||), matching the intent of filtering
to contacts who haven't hidden stories
- Remove manual sendStorySyncMessage call, as the library's sendStory
already handles sync internally
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHzM2XLKQoX9iraEdhoh3h
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Group sends built the recipient list from the full group membership, so
members already known to be unregistered were retried on every send via
the legacy 1:1 fan-out. On large groups this made a single send take
tens of seconds and could time out, leaving the message undelivered.
Filter out recipients whose unregistered timestamp is set before
sending, returning an unregisteredFailure result for each (so callers
and CLI output are unchanged) without the network attempt. The flag is
maintained independently by profile/CDS discovery and is cleared when a
recipient registers again, so skipped recipients are re-included
automatically.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Without an initial flush(), the JVM HttpServer buffers all
output until the first flush() in the 15-second keep-alive loop.
Clients with shorter timeouts (e.g. 10 s) abort before receiving
any data.
Add a flush() call directly after creating ServerSentEventSender,
before the wait loop, so the HTTP 200 response and headers reach the
client immediately upon connection.
Adds regression test SseInitialFlushTest that verifies at least one
byte arrives within 2 seconds of connecting to GET /api/v1/events.
When filling or updating a V2 group, profile keys were copied from
DecryptedGroup.members into the local profile store but not from
requestingMembers. Admins who never had a prior session with a user in
the join queue then lacked profile keys and could not decrypt profiles
(e.g. for listContacts).
Also process DecryptedRequestingMember entries the same way as full
members, using DecryptedMember / DecryptedRequestingMember types so the
lib module does not require a direct protobuf dependency.
Made-with: Cursor
