Recent searches
Search options
Hey @hongminhee
currently blasting random thoughts about #ActivityPub to fedi which are important at least to me at the first workday of the shiny Year of the Fediverse.
About
https://community.nodebb.org/topic/51fbaabb-7f67-4021-8fdf-06109242df69/null?_=1735825467776
Do you think this makes sense?
Perfectly yes !!!
It is exactly the way we use it in redaktor and I can invite you in github that you can see which relations we use.
Would it be appropriate to put Link objects in the attachment?
Well, it would be "appropriate" if they
"identify a resource attached or related to an object that potentially requires special handling." or are "at least semantically similar to attachments in email." -
it feels bad and the reason that [poor, non-conformant but] big solutions are not supporting "multiple values" feels essentially wrong. I am deeply sorry :)
1/x
Justification:
It is against the Linked Data Principles.
If any value in the spec. is not marked "functional" assume, there _are_ multiple values.
It is the opposite of "Be liberal in what you expect and strict in what you send".
It means "freezing" the fediverse.
:)
Let me explain it with two screenshots of the redaktor UI.
Data here is rather fake to show the use of multiple _different_ relations.
But any item like https://www.wikidata.org/wiki/Q1055 would have lots of relations.
In a Profile, the URLs are shown close to the summary ("above the fold") while the "attachment" would just be the links in a box which the user has to click (similar to the "attachments" in eMail) ...
Not shown here but would be possible.
2/3
But I need to stress the Conformance Section https://www.w3.org/TR/activitypub/#conformance
We are only "conformant" if we support "the entirety" of the protocol parts.
Cause only "the entirety" makes perfectly sense.
And it is up to us to start it. Right Now.
Not freezing cause of poor implementations.
Welll, this was my 2025 wish :)
3/3
I forgot to mention that anything screenshotted is fresh / HTML & CSS only
So, it just needs two extra things in any UI to support multiple items anywhere:
If you have multiple `type` and want to visualize them distinct have some "icon checkboxes" with
.item:has(.xy:checked) or .xy:checked + .item according to the structure …
(screenshot 1)
For all other properties, if you are not in a 1-column-scroll-context or need a fixed height / ratio, it is then just an arrow on the left and right.
The arrows are labels.
CSS translate-X-es anything, the content in an animated way and the arrow labels immediately so it is just CSS.
Super benefit:
We see a Link in e.g. the describes property which is another LD-item, we can check all alternate, languages and other relations
(wikidata in the example, gif screenshot 2 [old, meanwhile nicely styled])
The thing is that the discussion has a long and sad history.
If scientists, public institutions or broadcasters, journalists, NGOs say they can't use the protocol because no support for multiple, factual/scientific/historic/... relations, multilanguage and the reason is "big implementors don't support it", it is a vicious circle.
What I do, is inflating anything to the specification, apart from the LD parsers, this is 1 function in TS like
https://gist.github.com/sebilasse/3c1566846146d4ed7be007076e572165
If you get e.g.
{ "@language": "fr", "summary": "Voilá, Croissants" }
it becomes
{ "summaryMap": {"fr": ["Voilá, Croissants"]} }
and it is extendable, for example if no default JSON-LD language is given, I use it with options language.detect which is a function to autodetect 852 languages.