Following up on some questions here as discussed by email.

I see T249065 which has since been created. Does this mean the TechComm process is on the menu now?

Yes, we decided to submit our plans for comment via the TechCom RFC process after all. I believe we're at or near the end of that process. It's been quiet, although I see we had some late-breaking comments come in last night.

T249065 outlines end game outcomes for Q4 (So July 31st of this year). Is this timeline still active as of Covid-19 availability changes?

Yes, our plan is to stick to that timeline, with the initial launch narrowly scoped to supporting only the apps (not web), and supporting only existing Echo notification types. (On a side note, I think end of Q4 is June 30, not July 31?)

Cassandra seems like the data store of choice here in the design phase. Have you spoken with the data persistence team about this? My understanding is cassandra currently has limited use cases, and is not supported fully by SRE. That would seem to mean whoever are the current stewards need to be onboard with supporting this use case, or the product team needs to maintain their own Cassandra infrastructure. This may have changed in the last 18months. Depending on stewardship of the underlying data store there are security implications inherent to support and ownership.

We've been in contact with @Eevans about prospectively having the service component of this infrastructure manage the storage of push subscriptions in Cassandra. My understanding in general is that it would be a technically feasible choice, and that there's plenty of unused capacity in the Cassandra cluster currently used for session storage.

We've been relying on Cassandra in the Foundation's services platform for a few years now, so I had assumed that there was at least some baseline guarantee of SRE support for it. That said, I don't know what the current service level agreement (if any) is between SRE and CPT with respect to Cassandra operations. We'll follow up on that.

The document is unclear to me as far as the July 31st aim of integration with Echo. Will Echo rely on Cassandra after this timeline? I'm assuming no with the creation of an extension to leverage Echo itself, but the relationship targeted between these two extensions at implementation phases is unclear to me.

Sorry, it sounds like the diagram or description may be misleading on this point. As currently proposed, any data storage in Cassandra would be managed by the Node.js service. Any data storage needs of the PushNotifications extension will be handled in the existing MediaWiki MySQL cluster. The plan is for the service to manage device push subscription storage (in Cassandra), and for the extension to manage a (MySQL) table mapping global wiki user IDs to device push subscriptions. It will be the client's responsibility to add or remove associations between push subscriptions registered with the service and wiki user accounts; the intention is that subscriptions managed by the service be relatively long-lived (and support anonymous users), and that the mappings managed by the extension between these subscriptions and wiki user accounts be shorter-lived, i.e., created on login and deleted on logout.

Does this answer your question? Sorry, I'm not quite clear on how the timeline element plays into it. This won't create any direct dependency on Cassandra from Echo (or the PushNotifications extension), if that's what you're asking.

Can we wrap our arms around what kind of data can be pushed and define some policy to this effect? Leveraging the provider native platforms for messages makes sense, but only if we have strict rules about what information can transit. These policies should be in place prior to any deployment for safe handling into posterity before any deployment.

Created T251204 re: definition of such a policy. As noted there, one option we've been exploring is that of sending no data via the third-party push services, but rather pushing empty messages that serve only to prompt the app or browser to wake up and retrieve messages from Wikimedia's servers. This would arguably muddy up the architecture somewhat, but with the benefit of effectively eliminating an entire class of potential problems around user privacy.

In relation to above, the design doc currently does not address content traversal over provider platforms and encryption. I note that depending on classification of data we may have different problems to solve, but also that each provider network has a different implementation for E-2-E encryption and privacy expectations. (Google, Apple). In general, there is no trust relationship between ourselves and these messaging backplanes and so they should be treated as wild west as the general internet. There will be exposure for at-risk populations if confidentiality is not preserved, etc.

We have looped you into that discussion, which is happening separately. (The above comment about a potential zero-content push message model also applies here.)

Jacob & Aeryn. I'm just subscribing you here to bypass the ACL so you'll have access to all relevant context across conversations.

Note: T246712 stalled and backlogged for now.

Adding others from PI who will be involved in implementing this.

Just to be clear: is it OK to discuss potential privacy risk mitigation strategies at this point on the public RFC? I'd presume so; the code will be open-source, after all.

In T251190#6152489, @Mholloway wrote:

Just to be clear: is it OK to discuss potential privacy risk mitigation strategies at this point on the public RFC? I'd presume so; the code will be open-source, after all.

Absolutely, as long as folks refrain from discussing actual vulnerable code within WMF production. Which of course could not be the case here.