[bug] Unable to interact with ktistec users

[lindsayzhou]

Describe the bug with a clear and concise description of what the bug is.

I send a follow request to a ktistec user, and he didn't receive that.

Ktistec requires (created) http signature header.

Gts' implemetation doesn't include it: https://github.com/superseriousbusiness/gotosocial/blob/b7c629a18a3154b7cf8231ce6e4cbb47e8c32730/internal/transport/signing.go#L28-L29

Mastodon attempts to use the (created) header first, fallback to the Date header if not present.

The spec draft recommends using the created signature parameter (not required)

Log

From Gts server: timestamp="21/04/2024 20:46:22.302" func=workers.(*clientAPI).CreateFollowReq level=ERROR requestID=v9vv204f040018tk485g msg="error federating follow request: Follow: error sending activity *typefollow.ActivityStreamsFollow via outbox https://moe.reisen/users/lindsay/outbox: func1: error delivering to https://qaq.land/actors/qaq/inbox: deliver: POST request to https://qaq.land/actors/qaq/inbox failed: status=\"400 Bad Request\" body=\"{\"msg\":\"can't be verified\"}\""

From Ktistec server:

INFO - verification failed: (created) header must be signed
WARN - Ktistec::Open.open? - Does not exist [404]: https://moe.reisen/users/lindsay/follow/<signature_string>

What's your GoToSocial Version?

v0.15.0

GoToSocial Arch

x86_64 Binary

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Anything else we need to know?

No response

[tsmethurst]

Thanks! I'll see if we can rejig our signature without breaking compatibility for anything else. Didn't realize (created) was recommended.

[daenney]

It's recommended, not required, so any implementation that aims to correctly implement the spec should accept a signature without that field.

RECOMMENDED. The created field expresses when the signature was created. The value MUST be a Unix timestamp integer value. A signature with a created timestamp value that is in the future MUST NOT be processed. Using a Unix timestamp simplifies processing and avoids timezone management required by specifications such as RFC3339. Subsecond precision is not supported. This value is useful when clients are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments.

The last bit is kinda crucial:

This value is useful when clients are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments.

GtS is able to control that header just fine, and we do. It's hopefully not too much faff to add the attribute on our side, but implementing a stricter requirement than the spec is a bug, at least from an interoperability point of view.

[tsmethurst]

Hiya! Reopening this because we had to roll back (created) temporarily as it breaks compatibility with other softwares. We'll put it back in place as soon as other softwares update to be able to handle (created) properly. Tracking that here: https://github.com/superseriousbusiness/gotosocial/issues/2991

[tsmethurst]

Looks like this has been resolved on ktistec's side (see https://github.com/toddsundsted/ktistec/issues/103), so I will close this for now. We have a separate issue for switching to (create) at some point: https://github.com/superseriousbusiness/gotosocial/issues/2991