unifiedpush / specifications Goto Github PK

see discussion in #unifiedpush-devs:matrix.org. Will post more details and ideas soon.

This would help to be able to display a user-friendly name in apps.

https://www.rfc-editor.org/rfc/rfc9205.html new RFC. Should review the server spec and use advice from this.

Can we expand this or make separate standard between Push Server and Push Distributor?

This could be done in a Web Push compatible way by using Content-Encryption, see https://www.rfc-editor.org/rfc/rfc8291.html.

The party generating the payload needs to encrypt, and client libraries need to decrypt. The rest of the infrastructure can just pass-through the encrypted data.

Ref ircv3/ircv3-specifications#471, which has some WIP patches for this. See https://git.sr.ht/~emersion/PushGardenTestApp for a decryption example on Android.

Messages should be passed around as byte arrays not strings. Encoding encrypted bytes to UTF-8 results in garbage decoding.

This was recently discussed in #unifiedpush-devs:matrix.org with relation to binwiederhier/ntfy#101

The spec will probably have to be updated to change data types. This issue exists to keep track of progress regarding that.

Add support for account/password authencation.

Check: binwiederhier/ntfy#808 (comment)

It would be nice to add support for OPTIONS to push endpoints. This would allow the HTTP clients to check which methods are supported and check CORS.

Following the lengthy discussion in UnifiedPush/flutter-connector#56, and since we are potentially up for some breaking changes I would like to propose a change from token to instance in the spec.

They are supposed to be almost the same but doesn't have the exact same semantic, and this is both confusing and error-prone I believe.

Main change in the spec would be the rename + relax the constraint regarding the need to be random, but keep the uniqueness.

Implications (good or bad) I can think off:

• no potential misuse by an app/lib that would ignore the random token requirement
• mimic current lib interfaces
• Distributors can't rely on that to be a random string that can be used for auth and/or uniqueness. They will have to store a mapping. This is however already the case for most of them. People writing distributors should have better knowledge of the spec than people dealing with the connector interface, hence I think this is fine.

For backward compatibility:

• existing UP distributors that currently directly used the random token should be able to do token=token in their initial instance-token mapping when upgrading
• we can keep support for token EXTRA param in the Android code and treat it as an instance for a while until all apps/framework migrate
• for D-Bus, parameters are unnamed I believe, so no change should be needed at the interface level. We can just use current positional string token parameter as instance.

See: https://codeberg.org/iNPUTmice/up/issues/1

How are we handling retries? Should we implement RFC8030's TTL? If so, should it be a MUST not deliver after time or SHOULD not deliver after time (i.e. is TTL a required feature)?

One possible solution from @iNPUTmice:

A push server that implements storage and multiple delivery attempts SHOULD implement the TTL and Topic headers from RFC 8030. According to RFC 8030 §5.2 a push service MAY retain a push message for a shorter duration than requested; since this value can be 0 a push server that does not store messages is still a valid WebPush service. Push servers that do not implement storage MUST include a TTL: 0 header in the response.

The WebPush spec states:

Push services might need to limit the size and number of stored push
messages to avoid overloading. To limit the size of messages, the
push service MAY return a 413 (Payload Too Large) status code
[RFC7231] in response to requests that include an entity body that is
too large. Push services MUST NOT return a 413 status code in
responses to an entity body that is 4096 bytes or less in size.

Currently, the UP limit is 4000. We should consider changing this for better WebPush compatibility; it's only a 96 byte increase.

From what I remember, we originally did 4000 to make FCM Distributor work within FCM's 4096 limit. Now, we are running into size problems with FCM anyway due to base64 encoding, so adding another 96 bytes shouldn't be that big a deal (as long as UnifiedPush/fcm-distributor#56 is dealt with in some way)

https://www.freedesktop.org/wiki/Specifications/

This would be nice once linux spec has gotten some adoption.