AsamK
[Feature Request] Add stories compatibility
Adding support for stories, including managing story groups would be useful.
I'm making a bot which manages and creates stories for me, so I'd love to see this be added as a feature.
Also would like to see this enhancement. Would be willing to contribute to implementation and/or testing if desired.
The first step would be to design a cli interface for sending stories (maybe sendStoryMessage) and managing distribution lists for story groups (maybe listStoryDistributionLists and updateStoryDistributionList) with parameters for all the different functionalities.
Is it required by the Signal protocol to actually have a distribution list? Having a way to send stories without one would be nice to see (maybe via the recipients array?) for huge constantly-changing lists, but that's probably better off as a side-quest for the minute.
On Thursday, October 24, 2024 05:05 AEST, Sebastian Scheibner @.***> wrote:
The first step would be to design a cli interface for sending stories (maybe sendStoryMessage) and managing distribution lists for story groups (maybe listStoryDistributionLists and updateStoryDistributionList) with parameters for all the different functionalities. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/AsamK/signal-cli/issues/1592#issuecomment-2433214900", "url": "https://github.com/AsamK/signal-cli/issues/1592#issuecomment-2433214900", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
I would have to dig deeper into the code to check whether it's actually required. It will definitely be more efficient to use distribution lists when sending multiple stories to the same set of people, because it can reuse the sender key. For sending stories to an existing group it might not matter, but that needs to be checked.
I would have to dig deeper into the code to check whether it's actually required. It will definitely be more efficient to use distribution lists when sending multiple stories to the same set of people, because it can reuse the sender key. For sending stories to an existing group it might not matter, but that needs to be checked.
Fair, but for certain use cases, having specific recipients would be useful rather than constantly updating a distribution group (this is the case for a bot I'm currently making and depends on this feature request, it would read Signal UUIDs from an encrypted database and send update logs to them whenever an update occurs).
I would like to confirm I'm on the right track in terms of adding signal-cli interface.
First, it looks to me that in terms of the libsignal call to implement this new signal-cli api, the primary method in the whisper API seems to be:
org.whispersystems.signalservice.api.SignalServiceMessageSender.sendGroupStory(DistributionId, Optional<byte[]>, List<SignalServiceAddress>, List<UnidentifiedAccess>, GroupSendEndorsements, boolean, SignalServiceStoryMessage, long, Set<SignalServiceStoryMessageRecipient>, PartialSendBatchCompleteListener)
The impl of the above method seems to (mostly) turn around and call this method
org.whispersystems.signalservice.api.SignalServiceMessageSender.sendGroupMessage(DistributionId, List<SignalServiceAddress>, List<UnidentifiedAccess>, GroupSendEndorsements, long, Content, ContentHint, Optional<byte[]>, boolean, SenderKeyGroupEvents, boolean, boolean)
which calls:
org.whispersystems.signalservice.api.SignalServiceMessageSender.sendSenderKeyDistributionMessage(DistributionId, List<SignalServiceAddress>, List<SealedSenderAccess>, SenderKeyDistributionMessage, Optional<byte[]>, boolean, boolean)
which calls
org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessageRx(SignalServiceAddress, SealedSenderAccess, long, EnvelopeContent, boolean, CancelationSignal, SendEvents, boolean, boolean, int)
which sends messages over a socket and receives responses.
question: Is it appropriate to define the signal-cli 'sendStoryMessage' to use the whispersystems sendGroupStory? sendGroupStory appears to have be primarily for delivering to one group (as the name implies), and not to specific recipients as @LunarN0v4 suggests would be a good feature. Or, would a it make more sense to not use sendGroupStory, and make the 'lower level' calls (e.g. sendSenderKeyDistributionMessage) in the signal-api impl?
Or perhaps two API methods: 'sendStory', and 'sendGroupStory'? Thanks.
The most high level method should be used, so SignalServiceMessageSender.sendGroupStory should be the correct one.
In the official clients all story messages are sent to predefined recipient lists, that's why the method has group in its name. Sending to specific recipients should work by just creating a random distributionId, but I haven't checked if that might have other side effects.
I think just one method should suffice, sendStory or sendStoryMessage, that takes one or multiple RECIPIENT and -g group ids.
WDYT of this declaration ...in the Signal interface:
long sendStoryMessage(
String message, List<String> attachments, List<String> recipients, List<byte[]> groupIds
) throws Error.AttachmentInvalid, Error.Failure, Error.InvalidNumber, Error.UntrustedIdentity;
Would love this feature. Interested in building a bot that receives, manages, and creates stories.
How large of a project is this feature request?
long sendStoryMessage( String message, List<String> attachments, List<String> recipients, List<byte[]> groupIds ) throws Error.AttachmentInvalid, Error.Failure, Error.InvalidNumber, Error.UntrustedIdentity;
I propose simplifying to:
long sendStoryMessage(String messageText, List<String> attachments, byte[] groupId ) throws Error.AttachmentInvalid, Error.Failure, Error.InvalidNumber, Error.UntrustedIdentity;
I have the beginnings of an implementation for this method, along with Manager impl modelled after sendGroupMessage. If there is someone interested/available for review I would appreciate.