accept activities have invalid IDs #313

New issue

Closed

opened 2018-11-14 00:47:45 +00:00 by puckipedia · 1 comment

puckipedia commented

2018-11-14 00:47:45 +00:00

(Migrated from github.com)

fcf911fac9/plume-models/src/follows.rs (L72)

if I send a follow with ID https://example.com/mypersonalpage/follow/plume_blog, the response Accept will be at https://example.com/mypersonalpage/follow/plume_blog#accept, which is bad as it implies that example.com owns the object, which is not the case. As such, kroeg wisely ignores the incoming object, meaning that Accepts of follows never arrive. My suggestion is to either generate a random path on the blog's path (e.g. https://contoso.com/12345678-1234-1234-12345678) and use that, or use something like https://contoso.com/~/Username#accepts/{internal follow ID} instead, both hosted on the domain of the blog itself.

https://github.com/Plume-org/Plume/blob/fcf911fac97955112d28ef7c5fb54533ae3c0de6/plume-models/src/follows.rs#L72 if I send a follow with ID `https://example.com/mypersonalpage/follow/plume_blog`, the response Accept will be at `https://example.com/mypersonalpage/follow/plume_blog#accept`, which is bad as it implies that `example.com` owns the object, which is not the case. As such, kroeg wisely ignores the incoming object, meaning that `Accept`s of follows never arrive. My suggestion is to either generate a random path on the blog's path (e.g. `https://contoso.com/12345678-1234-1234-12345678`) and use that, or use something like `https://contoso.com/~/Username#accepts/{internal follow ID}` instead, both hosted on the domain of the blog itself.

👍 2

KokaKiwi commented

2018-11-23 00:28:37 +00:00

(Migrated from github.com)

Additionally, by AP spec (section 3.1), server-to-server Activity IDs MUST be dereferencables, so the Accept activity should also be available on the generated ID

(although I don't think the ID for Accept activities are actually dereferenced, so maybe the activity representation on backend can be skipped for now)

Additionally, by AP spec (section 3.1), server-to-server Activity IDs *MUST* be dereferencables, so the Accept activity should also be available on the generated ID (although I don't think the ID for Accept activities are actually dereferenced, so maybe the activity representation on backend can be skipped for now)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Plume/Plume#313

No description provided.

Rows
Columns