Move models and refactor import + send multiples images by apentori · Pull Request #69 · status-im/status-python-sdk

apentori · 2026-10-07T15:31:56Z

Include :

[Account] Send multiple images #67

Signed-off-by: apentori <pentori.alexis@proton.me>

* add missing param for messages * Listen to all messages * handle sending multiple images Signed-off-by: apentori <pentori.alexis@proton.me>

Signed-off-by: apentori <pentori.alexis@proton.me>

nickninov · 2026-10-07T18:07:17Z

+__all__ = [
+    "Community",
+    "Channel"
+]


Not a fan of __all__ maintenance. Usually from status_sdk import * is a bad practice and could be avoided. __all__ doesn't really make a difference in VS Code.

i can remove it if you don't want it

nickninov · 2026-10-07T18:08:08Z

-    def listen_requests(self) -> Generator[models.CommunityRequest, None, None]:
+    def listen_requests(self) -> Generator[CommunityRequest, None, None]:


I'd rather keep models so it's clear the file name this comes from. It's better for readability context

Please review - status-im/status-bot#33

I totally disagree with you on this

nickninov · 2026-10-07T18:10:55Z

+class MessageContentTypeEnum(IntEnum):
+    UNKNOWN_CONTENT_TYPE = 0
+    TEXT_PLAIN = 1
+    STICKER = 2
+    STATUS = 3
+    EMOJI = 4
+    TRANSACTION_COMMAND = 5  # deprecated
+    SYSTEM_MESSAGE_CONTENT_PRIVATE_GROUP = 6  # local only
+    IMAGE = 7
+    AUDIO = 8
+    COMMUNITY = 9
+    SYSTEM_MESSAGE_GAP = 10  # local only
+    CONTACT_REQUEST = 11
+    DISCORD_MESSAGE = 12
+    IDENTITY_VERIFICATION = 13
+    SYSTEM_MESSAGE_PINNED_MESSAGE = 14  # local only
+    SYSTEM_MESSAGE_MUTUAL_EVENT_SENT = 15  # local only
+    SYSTEM_MESSAGE_MUTUAL_EVENT_ACCEPTED = 16  # local only
+    SYSTEM_MESSAGE_MUTUAL_EVENT_REMOVED = 17  # local only
+    BRIDGE_MESSAGE = 18


This is just a direct copy from status-go Python code. In status-python-sdk users should not really worry about the internal int values.

yes that why i made the enum.
You were transforming everything as string for no reason except making any check more annoying

You were transforming everything as string for no reason except making any check more annoying

Makes it easier for final output. If you look at CommunityRequest and ContactRequest the values are converted to bool. Could be expanded when things are a bit more stable.

nickninov · 2026-10-07T18:14:50Z

+def in_docker() -> bool:
+    if os.path.exists("/.dockerenv"):
+        return True
+    try:
+        with open("/proc/1/cgroup") as f:
+            return any("docker" in line or "kubepods" in line for line in f)
+    except OSError:
+        return False


We can just determine that based on the /health REST call. status-go builds already have a specific format and docker compose has another way.

900dc82

The empty /health call is just due to a bug in the Status Backend code. That's not a prooer way of determining if you are in a container or not.
Also nothing ensure you the Backend is not run as a docker container while the sdk is not.

/health being empty is not a bug. It has parameters that are passed while the build is made. This does not appear in builds and latest docker compose. {} will appear only if the user does the build manually with Docker.

This code can brake if Docker does not give you privileges:

with open("/proc/1/cgroup") as f: return any("docker" in line or "kubepods" in line for line in f)

It's safest to rely on status-go to determine if it's a build or not. I already has some privilege issues with Hermes.

nickninov · 2026-10-07T18:21:02Z

+    def __send_content(
+            self,
+            chat_id: str,
+            message: Optional[str] = None,
+            reply_to_message_id: Optional[str] = None,
+            image_paths: Optional[list[str]] = None,
+            bridged_content: Optional[BridgedContent] = None
+        ) -> str:


This implementation is bad and will break in future when audio is added. 2026-H2:

2.41 - Record and send audio messages

2.41 - File sending over Codex

I've made a commit in version/1.2.2 that will work with other file paths as well.

i let you rebase and add your fix here then !

nickninov · 2026-10-07T18:26:31Z

+                yield Message.from_raw(event["body"]["message"])

-    def listen_messages(self) -> Generator[models.Message, None, None]:
+    def listen_messages(self, listen_types: list[int] = []) -> Generator[Message, None, None]:


listen_messages should return you all of the ALLOWED_CONTENT_TYPES messages. Devs should do the filtering on their side.

Also listen_types: list[int] = [] is a bad practice. It's better to use listen_types = None to avoide side effects.
https://pybit.es/articles/the-mutable-trap-avoiding-unintended-side-effects-in-python/

If you want to listen for stuff with signal. Please go over the docs.

Well it's simpler if it's possible to do the filtering just by passing an argument to the function.
And since you were filtering the message inside the function i kept this functionnality https://github.com/status-im/status-python-sdk/blob/master/status_sdk/account.py#L974

Also listen_types: list[int] = [] is a bad practice. It's better to use listen_types = None to avoide side effects.

Then you will have to inverse all the logic and make use the parameter be excluded_types to ensure people don't have to pass all the events if they want to listen to everything

There are functions that do different things in class Account, class GroupChat and class Community. They predate status-bot. Either use the ready functions or do the raw implementation in the base module in the bot. Users should not have to tinker with enums and worry about message types.

Current implementation will return a message as it appears in Status App:

In status-go everything is a message so I would avoid that terminology.

Well I can move all of this into a new function listen_events so you are happy and i can use it in the Bot

listen_event is a bad name because Status App "events" such as:

Send friend request

Contact removing you

Accepted request

Community member request

@everyone or @display_namme mentions

Exist inmessages.new and local-notifications. Also you will have to filter out all of the Waku and wallet events. Use account.signal.listen without passing a signal_type. This will already return everything. Do the filtering on your side. Example can be found in class Account (but with signal_type).

nickninov · 2026-10-07T18:27:59Z

 [project]
 name = "status-sdk"
-version = "1.2.1"
+version = "1.3.0"


We just needed the image functionality - not so many unnecessary commits. These refactors are unnecessary at this stage. I will start integrating them bit by bit with the Hermes CLI.

The change of listen_message is required for the Bot to use the Models and the listen_message function.
The refactoring of import and moving the files is a start to improve the code clarity

The change of listen_message is required for the Bot to use the Models and the listen_message function.

The current version dumps everything in a single BaseModule. This seems like an issue with status-bot and not the listen_message implementation. As previously discussed, the code has to be split into sub modules. It will be easier to maintain and develop even without using AI.

You should have different def on_event implementations.

I need a listener that return all the event, not 5 different listener function.

I need a listener that return all the event, not 5 different listener function.

Use account.signal.listen without passing a signal_type. This will already return everything. Do the filtering on your side. Example can be found in class Account (but with signal_type).

nickninov · 2026-10-11T18:38:53Z

Changes have been made in:

apentori added 7 commits September 29, 2026 09:56

refactor: move models in directory

f0507aa

Signed-off-by: apentori <pentori.alexis@proton.me>

fix import

eb8aa13

Signed-off-by: apentori <pentori.alexis@proton.me>

fix: account and message issues

3327091

* add missing param for messages * Listen to all messages * handle sending multiple images Signed-off-by: apentori <pentori.alexis@proton.me>

fix import

f5cb397

Signed-off-by: apentori <pentori.alexis@proton.me>

fix imports

3b07ddf

Signed-off-by: apentori <pentori.alexis@proton.me>

fix message models

e8b9616

Signed-off-by: apentori <pentori.alexis@proton.me>

account: support only one image per __send_content

9ec09c5

Signed-off-by: apentori <pentori.alexis@proton.me>

apentori requested a review from nickninov October 7, 2026 15:31

apentori self-assigned this Oct 7, 2026

nickninov reviewed Oct 7, 2026

View reviewed changes

nickninov closed this Oct 11, 2026

nickninov deleted the listen-entire-messages branch October 11, 2026 18:40

		def listen_requests(self) -> Generator[models.CommunityRequest, None, None]:
		def listen_requests(self) -> Generator[CommunityRequest, None, None]:

Conversation

apentori commented Oct 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nickninov commented Oct 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants