Server sends phantom WebSocket pub messages

報告されている受信者の受信トレイへの POST から始め、結果として生成される pub メッセージに対するサーバーの WebSocket パブリケーション処理を追跡します。送信者と受信者の受信トレイの状態およびリクエストパスを比較し、その後、CRUD 操作が変更されたリソースに対してのみ通知が発行されることを確認します。

Based on the spec (https://github.com/solid/solid-spec/blob/master/api-websockets.md#subscription), client can subscribe and the server will send WebSocket pub messages on CRUD operations. I use this for inbox monitoring - notify user about new messages in his Solid inbox. So when anybody POSTs to his inbox, solid server sends WS pub message to my application, this works fine.

However, there are "phantom" WS pub messages even when there is no user-triggered CRUD operation on the inbox. From the spec, it should be only when POST, PUT, PATCH or, DELETE happens on the source.

Now, this is hard to debug/investigate. But I can reproduce it, using my application https://whyineedtofillusername.github.io/inbox/:

1. login using WebID
2. send a message to any other WebID (lastly I tried sending messages between https://inbox1.inrupt.net/profile/card#me and https://inbox4.inrupt.net/profile/card#me, using Activity Streams message functionality; one in Chrome and the other user in Firefox)

• the only request the application does is this POST request (copied from Chrome, user Inbox1 sending message to user Inbox4):

POST /inbox/ HTTP/1.1
Host: inbox4.inrupt.net
Connection: keep-alive
Content-Length: 437
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
Accept: application/json, text/plain, */*
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
Content-Type: application/ld+json
Origin: https://whyineedtofillusername.github.io
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://whyineedtofillusername.github.io/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

{..} (json payload)

The request above produces WS message

pub https://inbox1.inrupt.net/inbox/

Now there shouldn't be any reason for this, but it looks like the solid server is doing some CRUD operation on the sender's inbox as well. Is this intentional? When I compare the RDF for https://inbox1.inrupt.net/inbox/ before and after sending the message, there is no change (not even the "terms:modified" has changed). So it doesn't look like there's been any CRUD operation on the source.