split page into distinct ideas
parent
517f53676c
commit
a304590ba8
|
@ -104,4 +104,6 @@ but it's really that last one that seems most salient to me. consider an Article
|
|||
type: Note
|
||||
name: "Pronouns"
|
||||
content: "they/them"
|
||||
```
|
||||
```
|
||||
|
||||
note that Note might still have an id, though... so really it's just a vague ill-defined "intention". for example, maybe use a Note for a "status update" in a chat/presence sense? like XMPP PEP.
|
|
@ -0,0 +1,5 @@
|
|||
> Mention: A specialized Link that represents an @mention.
|
||||
|
||||
this is an incredibly narrow definition and also one that is often useless. what's so special about an @mention?
|
||||
|
||||
it would have been better to define it in terms of, idk, generating a notification or something? like a webmention?
|
|
@ -1,10 +1,3 @@
|
|||
+++
|
||||
+++
|
||||
|
||||
# the semantics of some types are unclear or poorly defined
|
||||
|
||||
## Note vs Article
|
||||
|
||||
see [Note vs Article]({{<relref "note-vs-article.md" >}}) for more. but basically:
|
||||
|
||||
in summary:
|
||||
|
@ -19,10 +12,4 @@ the messy general consensus post-spec seems to be about "intention", but this is
|
|||
|
||||
it would have been better to define it similarly to HTML `<article>` perhaps? an independent unit of writing? one that is published and therefore might reasonably be syndicated?
|
||||
|
||||
## Mention
|
||||
|
||||
> Mention: A specialized Link that represents an @mention.
|
||||
|
||||
this is an incredibly narrow definition and also one that is often useless. what's so special about an @mention?
|
||||
|
||||
it would have been better to define it in terms of, idk, generating a notification or something? like a webmention?
|
||||
and maybe Note should have been forced plaintext. idk. at the very least the distinction should be better explained.
|
|
@ -1,6 +1,3 @@
|
|||
+++
|
||||
+++
|
||||
|
||||
# extensibility for plain-json consumers is underconstrained
|
||||
|
||||
the recommendation in the spec is to use JSON-LD for extensions, which leaves open the "best practices" on how might one expect to serialize and parse those extensions.
|
||||
|
|
|
@ -1,6 +1,3 @@
|
|||
+++
|
||||
+++
|
||||
|
||||
activitystreams 2.0 defines some actor types like Person, Group, Organization
|
||||
|
||||
these types should not have been defined at all. they should have reused the vcard properties. the semantics of the types have led to mistakes such as people looking at Group and assuming that it's a facebook-style group, when that's not the definition at all.
|
Loading…
Reference in New Issue