* Show and enforce the terminated state of a group
A group admin can permanently terminate a group. Afterwards the group is
read-only for everyone, not even an admin can send messages or start calls;
members keep access to the existing history. Other clients silently drop
messages sent to a terminated group.
Read the DecryptedGroup.terminated flag through GroupInfo.isTerminated() and:
- surface it in listGroups (json and plain text) and as the DBus IsTerminated
group property
- refuse to send to a terminated group locally (messages, reactions, typing and
group stories) rather than send one that other clients ignore
- drop incoming messages addressed to a terminated group
* Add terminateGroup command to terminate a group for everyone
Let a group admin permanently terminate a GroupV2 group via the
TerminateGroupAction (Groups.proto field 28, change epoch 7) the pinned library
already exposes as GroupsV2Operations.createTerminateGroup().
- GroupV2Helper.terminateGroup builds and commits the change
- GroupHelper.terminateGroup resolves/refreshes the group (v2 only), sends the
update to members and syncs storage, with the same conflict-retry as
updateGroup
- exposed through Manager.terminateGroup, the terminateGroup CLI/JSON-RPC command
and the DBus Group.terminateGroup method
---------
Co-authored-by: FailSpy <FailSpy@users.noreply.github.com>
createAttachmentStream() never populated SignalServiceAttachmentStream's
width/height fields, even though the Builder has supported them since at
least the currently pinned libsignal-service version. Without them, other
Signal clients render outgoing image attachments as a square-cropped
thumbnail instead of their actual aspect ratio.
Probe dimensions via ImageIO for image/* attachments up to 20MiB (buffered
in memory only for that check) and pass them through to the builder.
Falls back to width/height 0 (today's behavior) for non-images, oversized
files, or anything ImageIO can't parse.
* Add group story support to core library layer
Extend Manager.sendStory() with an optional GroupId parameter and add
SendHelper.sendGroupStoryMessage() for endorsement-aware group story
delivery, laying the groundwork for group story support (task 1 of 4).
The existing My Story code path is unchanged.
* Add --group-id support to SendStoryCommand
Passes an optional GroupId through to Manager.sendStory so stories can
be posted to a group instead of only My Story, and surfaces
GroupNotFoundException / NotAGroupMemberException as user errors.
* Update stubs for 3-parameter sendStory and add empty-recipient guard
Updates DbusManagerImpl and StubManager (in SubscribeCallEventsTest) to
match the new 3-parameter sendStory signature: (String attachment,
boolean allowsReplies, Optional<GroupId> groupId).
Also includes the empty-recipient guard added after Task 1 review to
prevent stories from being sent to groups where the user is the only member.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MR2KF56Qcf9qNH1URj3XWs
* Document group story support in man page and changelog
- Add --group-id (-g) option to sendStory command in man page
- Update CHANGELOG to mention group story support via --group-id
- Maintain alphabetical order of options in sendStory section
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MR2KF56Qcf9qNH1URj3XWs
* Address review findings: endorsement safety and error handling
- Filter group story recipients by ACI type and endorsement availability
to prevent ClassCastException and NPE on edge cases
- Add empty-recipient guard after endorsement filtering
- Skip known-unregistered recipients before address resolution, matching
the pattern from sendGroupMessageInternal
- Add debug logging when recipients are filtered out
- Fix redundant error message prefixing in SendStoryCommand
- Add .superpowers/ to .gitignore
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MR2KF56Qcf9qNH1URj3XWs
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The cachedSessions HashMap grows with every unique (address, deviceId)
pair seen during message processing and is never evicted. In a
long-running daemon handling group messages, this causes linear memory
growth (~47 MB/hour observed) as SessionRecord objects accumulate for
every contact/device the daemon has ever communicated with.
Replace the unbounded HashMap with an LRU-bounded LinkedHashMap (access
order, max 1000 entries). Evicted sessions are reloaded from SQLite on
next access, so correctness is preserved.
Claude-Session: https://claude.ai/code/session_01HHzM2XLKQoX9iraEdhoh3h
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
