@jwz philips oneblade is amazing, it's another tier above any other electric shaver I've used

You Can See Everything was 10/10. One of the most insane movie experiences. Idk how you give people best actor/actress noms for a documentary but it should happen here.

FEP-8967: Generating link previews for attached links

https://w3id.org/fep/8967

Summary

A common feature in social applications is to show users a rich preview of a link included in the content of a message or post, before the user clicks the link. Currently, applications like Mastodon generate link previews for the first link found in the content, without considering the publisher's possible intent. This FEP allows publishers to explicitly signal which links are intended for special processing, using the existing attachment model. Optionally, publishers can include their own link preview information so that trusting consumers can skip generating their own previews.

Link in attachment

The attachment model can be used to indicate that something performs a particular function as an extension of the main content. [AS2-VOCAB] defines attachment as "semantically similar to attachments in email" for something that "potentially requires special handling".

Publishers MAY include a Link in attachment to signal that this link should be processed semantically as an attached link preview card, appearing similarly to attached images, attached videos, or attached audio. The link attachment MUST have an href, indicating that it is a Link.

{ "@context": "https://www.w3.org/ns/activitystreams", "attachment": { "href": "https://foo.example/" }}

Upon encountering an attachment that is a Link, consumers SHOULD show this link as "attached" to the object. At minimum, the href can be rendered directly, perhaps alongside an icon representing a link.

Link preview

Publishers MAY include link preview information using the preview property:

{ "@context": [ "https://www.w3.org/ns/activitystreams", { "sensitive": "as:sensitive" } ], "attachment": { "href": "https://foo.example/", "preview": { "type": "Article", "name": "Example Essay", "summary": "In which some information is provided...", "image": { "sensitive": true, "url": { "href": "https://cover-image.example/file.jpg", "mediaType": "image/jpg", "width": 1200, "height": 630 } }, "attributedTo": { "name": "The Author", "icon": { "url": { "href": "https://avatar.example/file.png", "mediaType": "image/png", "width": 48, "height": 48 } }, "url": { "href": "https://author.example/", } } } }}

The exact form of the preview and its processing model is out of scope of this FEP (as each consumer is free to render information according to their own design language and understanding), but some properties may be useful as equivalents of OpenGraph properties which are widely used for link previews:

• name -- similar to og:title, indicate the preview card's primary text.
• summary -- similar to the og:description, indicate the preview card's secondary text.
• image -- similar to og:image, indicate the preview card's image.
• type -- similar to og:type, indicate the type of the target resource. This can be used to select an appropriate icon representing the resource.
• attributedTo -- loosely similar to article:author, music:musician, music:creator, book:author, and other such properties, indicate the preview card's attribution.
  • name -- the name that should be attributed
  • icon -- the icon that should be displayed alongside the attributed name
  • url -- the link that should wrap the attribution

Consumers that do not trust the publisher's provided preview information MAY generate their own preview through whichever means they find appropriate, such as for example fetching the link target and extracting OpenGraph information or HTML tags such as </code> or <code><meta></code>.</p><p></p><h2>Alternative approaches</h2><p>(This section is non-normative.)</p><h3>Attaching objects directly</h3><p>Rather than attaching a Link with an optional preview, resources can be attached directly by their <code>id</code> along with arbitrary optional claims.</p><pre data-code-wrap="json"><code class="lang-json">{ "@context": "https://www.w3.org/ns/activitystreams", "attachment": { "id": "https://foo.example/", "type": "Article", "name": "Example Essay", // ... }}</code></pre><p>The difference between attaching an Object versus attaching a Link is that attaching an Object creates a direct relation between the current object and the attached object, whereas attaching a Link does not create this relation between two objects. For example, consider the difference between attaching an Image versus attaching a Link that targets an image. In most cases, directly attaching the Image is probably more appropriate. However, if the publisher attaches a Link instead, it might be because the link is present in the <code>content</code> and the publisher wishes to indicate this for special processing; for whatever reason, the publisher does not want to directly attach the Image. This depends on the specific details of the processing model, which is out of scope for this FEP.</p><h2>Implementations</h2><ul><li>Mastodon 4.5: Intent to publish Link in attachment, per [Mastodon-PR]. Publishing link preview information is not currently planned at this time; Mastodon will instead consume attached links by their <code>href</code> as a signal to generate link previews with their existing OpenGraph logic. In the future, Mastodon plans to stop automatically extracting the first link in <code>content</code>, but for now the first link is used as a fallback in case no <code>attachment</code> is present.</li></ul><h2>References</h2><ul><li>James M Snell, Evan Prodromou, [Activity Vocabulary][AS2-VOCAB], 2017</li><li>Gargron, [mastodon/mastodon#36104: Add support for Link objects in attachment][Mastodon-PR], 2025</li></ul><p>[AS2-VOCAB]: <a href="https://www.w3.org/TR/activitystreams-vocabulary/">https://www.w3.org/TR/activitystreams-vocabulary/</a>[Mastodon-PR]: <a href="https://github.com/mastodon/mastodon/pull/36104">https://github.com/mastodon/mastodon/pull/36104</a></p><h2>Copyright</h2><p>CC0 1.0 Universal (CC0 1.0) Public Domain Dedication</p><p>To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.</p>

PS OpenBSD has all the required drivers AFAIK

I get asked to review a lot of weird tech stuff for my blog. Here's the latest gadget being offered to me.

On the one hand, I'm fascinated to see how bad a privacy nightmare this could be.
On the other hand, I'm not sure I want to normalise this sort of thing.

So, should I get one of these to review? Please vote in the poll (next message).

okay, actually maybe i was a little bit too fast to say that i will migrate to sharkey, because you cant actually configure the feed in it with hashtags smh 😐

does anyone has a recommendation for some fedi-only instances please?
#fedi

maybe i should host my own instance of gts and use it instead..?
#fedi

It's amazing how critical *trying something* is to understanding it. Reading, watching a tutorial, searching, looking at code or opening a 3d model file... nothing beats entering, experimenting, *trying out the idea* to internalize it.

I kept forgetting how to prevent gimbal lock in terms of rotation order. I kept forgetting what the order *should be* in terms of the "least critical" axis, should it be in the middle, or the last?

It wasn't until I hooked together three toruses and tried making gimbals manually and seeing where the problem happened that I could internalize it.