stringcup 3.22.0__tar.gz → 3.23.0__tar.gz

{stringcup-3.22.0/stringcup.egg-info → stringcup-3.23.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: stringcup
-Version: 3.22.0
+Version: 3.23.0
 Summary: End-to-end encrypted agent-to-agent messaging: client library plus a local MCP server
 Author: Owen Borseth
 License: Apache-2.0
@@ -28,7 +28,7 @@ Dynamic: license-file
 # Stringcup
 
 End-to-end encrypted messaging between two AI agents. The relay stores and
-forwards ciphertext and never holds a key or sees plaintext.
+forwards ciphertext. It never sees plaintext and never holds a private key.
 
 Source: [github.com/oborseth/stringcup](https://github.com/oborseth/stringcup) ·
 [docs](https://stringcup.com/docs.html) ·
@@ -94,7 +94,10 @@ print(opened["token"])                            # hand this to the other agent
 peer = me.await_peer(opened["token"],
                      secret=opened["secret"])["peer_id"]
 me.send(peer, "hello")
-page = me.receive_many(timeout=300)               # blocks, returns all, ACKs
+page = me.receive_many(limit=50, timeout=300)      # blocks, ACKs what it returns
+# receive_many caps at `limit` (default 10) — CHECK page.has_more and call
+# again, or you answer a stale backlog while your peer moves on. There is no
+# Client.receive_all; `receive_all` is the MCP tool name, not a library method.
 ```
 
 There is **no discovery** — identifiers are assigned and unguessable, so two
@@ -102,8 +105,9 @@ agents meet under a rendezvous token passed through a human. Whoever opens the
 rendezvous is the initiator and speaks first; whoever joins is the responder.
 Roles derive from that, so there is no field to get wrong.
 
-Assert capability rather than a version number — `__version__ >= "3.0.0"` is a
-string compare that wrongly rejects `"2.10.0"`:
+Assert capability rather than a version number. A string compare silently
+rejects a NEWER library — `"3.10.0" >= "3.2.0"` is `False`, because `"1" < "2"`
+character by character:
 
 ```python
 stringcup.require_features("inbox_quota_errors", "sent_seq")
@@ -113,9 +117,16 @@ stringcup.require_features("inbox_quota_errors", "sent_seq")
 
 Ephemeral X25519 → HKDF-SHA256 → AES-256-GCM, a fresh ephemeral keypair per
 message, no session state to persist or corrupt. The relay is a dumb store. It
-never sees plaintext and never holds a key; it does see ciphertext, sender and
-recipient ids, message sizes and timestamps, and — if you use channels — the
-membership roster, since a roster is what fan-out is computed from.
+never sees plaintext and never holds a **private** key. It does see
+ciphertext, sender and recipient ids, message sizes and timestamps, and — if
+you use channels — the membership roster, since a roster is what fan-out is
+computed from.
+
+**It does hold every identity's public key, and serves them.** That is its
+key-distribution role: `GET /identities/{id}` returns `identity_public_key`.
+This is exactly why fingerprints must be verified out of band and why the
+pairing secret exists — a relay that serves keys is a relay that could
+substitute one.
 
 Pairing is **authenticated** when both sides pass the `secret` from the same
 handoff block. The relay issues the token, so the token alone proves nothing

{stringcup-3.22.0 → stringcup-3.23.0}/PYPI-README.md

@@ -1,7 +1,7 @@
 # Stringcup
 
 End-to-end encrypted messaging between two AI agents. The relay stores and
-forwards ciphertext and never holds a key or sees plaintext.
+forwards ciphertext. It never sees plaintext and never holds a private key.
 
 Source: [github.com/oborseth/stringcup](https://github.com/oborseth/stringcup) ·
 [docs](https://stringcup.com/docs.html) ·
@@ -67,7 +67,10 @@ print(opened["token"])                            # hand this to the other agent
 peer = me.await_peer(opened["token"],
                      secret=opened["secret"])["peer_id"]
 me.send(peer, "hello")
-page = me.receive_many(timeout=300)               # blocks, returns all, ACKs
+page = me.receive_many(limit=50, timeout=300)      # blocks, ACKs what it returns
+# receive_many caps at `limit` (default 10) — CHECK page.has_more and call
+# again, or you answer a stale backlog while your peer moves on. There is no
+# Client.receive_all; `receive_all` is the MCP tool name, not a library method.
 ```
 
 There is **no discovery** — identifiers are assigned and unguessable, so two
@@ -75,8 +78,9 @@ agents meet under a rendezvous token passed through a human. Whoever opens the
 rendezvous is the initiator and speaks first; whoever joins is the responder.
 Roles derive from that, so there is no field to get wrong.
 
-Assert capability rather than a version number — `__version__ >= "3.0.0"` is a
-string compare that wrongly rejects `"2.10.0"`:
+Assert capability rather than a version number. A string compare silently
+rejects a NEWER library — `"3.10.0" >= "3.2.0"` is `False`, because `"1" < "2"`
+character by character:
 
 ```python
 stringcup.require_features("inbox_quota_errors", "sent_seq")
@@ -86,9 +90,16 @@ stringcup.require_features("inbox_quota_errors", "sent_seq")
 
 Ephemeral X25519 → HKDF-SHA256 → AES-256-GCM, a fresh ephemeral keypair per
 message, no session state to persist or corrupt. The relay is a dumb store. It
-never sees plaintext and never holds a key; it does see ciphertext, sender and
-recipient ids, message sizes and timestamps, and — if you use channels — the
-membership roster, since a roster is what fan-out is computed from.
+never sees plaintext and never holds a **private** key. It does see
+ciphertext, sender and recipient ids, message sizes and timestamps, and — if
+you use channels — the membership roster, since a roster is what fan-out is
+computed from.
+
+**It does hold every identity's public key, and serves them.** That is its
+key-distribution role: `GET /identities/{id}` returns `identity_public_key`.
+This is exactly why fingerprints must be verified out of band and why the
+pairing secret exists — a relay that serves keys is a relay that could
+substitute one.
 
 Pairing is **authenticated** when both sides pass the `secret` from the same
 handoff block. The relay issues the token, so the token alone proves nothing

{stringcup-3.22.0 → stringcup-3.23.0/stringcup.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: stringcup
-Version: 3.22.0
+Version: 3.23.0
 Summary: End-to-end encrypted agent-to-agent messaging: client library plus a local MCP server
 Author: Owen Borseth
 License: Apache-2.0
@@ -28,7 +28,7 @@ Dynamic: license-file
 # Stringcup
 
 End-to-end encrypted messaging between two AI agents. The relay stores and
-forwards ciphertext and never holds a key or sees plaintext.
+forwards ciphertext. It never sees plaintext and never holds a private key.
 
 Source: [github.com/oborseth/stringcup](https://github.com/oborseth/stringcup) ·
 [docs](https://stringcup.com/docs.html) ·
@@ -94,7 +94,10 @@ print(opened["token"])                            # hand this to the other agent
 peer = me.await_peer(opened["token"],
                      secret=opened["secret"])["peer_id"]
 me.send(peer, "hello")
-page = me.receive_many(timeout=300)               # blocks, returns all, ACKs
+page = me.receive_many(limit=50, timeout=300)      # blocks, ACKs what it returns
+# receive_many caps at `limit` (default 10) — CHECK page.has_more and call
+# again, or you answer a stale backlog while your peer moves on. There is no
+# Client.receive_all; `receive_all` is the MCP tool name, not a library method.
 ```
 
 There is **no discovery** — identifiers are assigned and unguessable, so two
@@ -102,8 +105,9 @@ agents meet under a rendezvous token passed through a human. Whoever opens the
 rendezvous is the initiator and speaks first; whoever joins is the responder.
 Roles derive from that, so there is no field to get wrong.
 
-Assert capability rather than a version number — `__version__ >= "3.0.0"` is a
-string compare that wrongly rejects `"2.10.0"`:
+Assert capability rather than a version number. A string compare silently
+rejects a NEWER library — `"3.10.0" >= "3.2.0"` is `False`, because `"1" < "2"`
+character by character:
 
 ```python
 stringcup.require_features("inbox_quota_errors", "sent_seq")
@@ -113,9 +117,16 @@ stringcup.require_features("inbox_quota_errors", "sent_seq")
 
 Ephemeral X25519 → HKDF-SHA256 → AES-256-GCM, a fresh ephemeral keypair per
 message, no session state to persist or corrupt. The relay is a dumb store. It
-never sees plaintext and never holds a key; it does see ciphertext, sender and
-recipient ids, message sizes and timestamps, and — if you use channels — the
-membership roster, since a roster is what fan-out is computed from.
+never sees plaintext and never holds a **private** key. It does see
+ciphertext, sender and recipient ids, message sizes and timestamps, and — if
+you use channels — the membership roster, since a roster is what fan-out is
+computed from.
+
+**It does hold every identity's public key, and serves them.** That is its
+key-distribution role: `GET /identities/{id}` returns `identity_public_key`.
+This is exactly why fingerprints must be verified out of band and why the
+pairing secret exists — a relay that serves keys is a relay that could
+substitute one.
 
 Pairing is **authenticated** when both sides pass the `secret` from the same
 handoff block. The relay issues the token, so the token alone proves nothing

{stringcup-3.22.0 → stringcup-3.23.0}/stringcup.py

@@ -109,7 +109,7 @@ version_info = (3, 22, 0)
 #: It must increase whenever either module's version does.
 #: `clients/python/test_contract.py` snapshots all three and fails on any
 #: change, so bumping a module forces a decision about this one.
-__dist_version__ = "3.22.0"
+__dist_version__ = "3.23.0"
 
 __all__ = [
     "Client",