Re: Should the specs be forked and maintained elsewhere?

> namespacing is overkill for a lot of use cases [...] If plemora and
mastodon want to have common terms, in JSON, that's good

does this actually work cleanly? my understanding was that JSON-LD
processors cannot deterministically handle plain JSON they encounter that
isn't defined in @context. based on the JSON-LD playground, a `term`
without a mapping will expand to `_:term`; compaction may or may not copy
the `term` as-is or otherwise expand it; flattening will simply assign a
blank node identifier that replaces the `term` entirely with `b1`; framing
will assign `_:b1` to the property name. N-Quads will completely remove any
such statements where the predicate is not namespaced.

per as2-core, activitystreams documents are defined as compacted against
the activitystreams context at minimum, and there is this language
regarding undefined terms:
https://www.w3.org/TR/activitystreams-core/#jsonld

> Implementations may also use additional properties and values not defined
in the JSON-LD @context with the understanding that any such properties
will likely be unsupported and ignored by consuming implementations that
use the standard JSON-LD algorithms.

so we can't easily depend on "just" attaching properties as plain JSON.
unless we were to define a conformance profile spec that mandated "plain
JSON" support, and gave JSON-LD processors extra work to do. (currently,
the balance is the other way around; plain JSON parsers need to do extra
work to handle things like `Public` vs `as:Public` vs `
https://www.w3.org/ns/activitystreams#Public` being the same thing. generic
JSON-LD consumers can handle this case trivially.) we might similarly
imagine a conformance profile which mandated "plain JSON" *only*,
eliminating support for generic JSON-LD parsers and only supporting
"JSON-LD enabled Activity Streams 2.0 implementations" which special-case
the media-type `application/activity+json` and inject the normative
@context definition if it is missing (which in this case, it very well
might be). anyone wishing to use flattened or framed JSON-LD would not be
able to interoperate fully until such extension terms were defined.