diff --git a/proposals/4140-expiring-events-with-keep-alive-endpoint.md b/proposals/4140-expiring-events-with-keep-alive-endpoint.md
index ad16c189b..917bff149 100644
--- a/proposals/4140-expiring-events-with-keep-alive-endpoint.md
+++ b/proposals/4140-expiring-events-with-keep-alive-endpoint.md
@@ -31,22 +31,21 @@ Request
 
 ```json
 {
-  "content": {
     "m.will_expire": 10,
-    "other_content": "hello"
-  }
+    "body": "hello"
 }
 ```
 
 If the homeserver detects a `m.expired` field it will store and distribute the
-event as:
+event as hiding the timeout duration:
 
 ```json
 {
-  "content": {
+  "content":{
     "m.will_expire": "running",
-    "other_content": "hello"
-  }
+    "body": "hello",
+  },
+  "other_fields":"sender, origin_server_ts ..."
 }
 ```
 
@@ -72,8 +71,8 @@ The body contains the refresh token so the homeserver knows what to refresh.
 }
 ```
 
-The information of this endpoint is very limited so that almost no metadata is
-leaked when using this endpoint. This allows to share a refresh link to a different
+The information required to call this endpoint is very limited so that almost
+no metadata is leaked when. This allows to share a refresh link to a different
 service (an SFU for instance) that can track the current client connection state,
 and pings the HS to refresh and informs the HS about a disconnect.
 
@@ -127,6 +126,28 @@ an indicator to determine if the event is expired. Instead of letting the SFU
 inform about the call termination or using the call app ping loop like we propose
 here.
 
+---
+It might not be necessary to change the value of `"m.will_expire" = 10` to
+`"m.will_expire" = "running"` it makes it easier to understand and also
+hides more potential metadata but it is questionable if that bring any benefit.
+
+---
+The name `m.will_expire` has been chosen since it communicates that it becomes
+invalid. And that it is an event that automatically changes state
+(`will_expire` vs `expired`). But it does not imply what expired vs non expired
+means, it is flexible in how can be used.
+Alternatives could by:
+
+- `m.alive`
+  - pro: communicates it might change (alive is always temporal)
+  - con: ver strong bias on how to use it `valid/invalid`
+- `m.timeout`
+  - pro: very unbiased in how its used - timeout over can also mean the client
+  will show a reminder.
+  - pro: clear that it has something to do with time.
+  - con: not so clear the homeserver will automatically do sth.
+  - con: not so clear that this timeout can be refreshed?
+
 ## Security considerations
 
 We are using unauthenticated endpoint to refresh the expirations. Since we use