Cursor just launched Composer 2, a purpose-built coding model that outperforms Claude Opus 4.6 on CursorBench and dramatically undercuts rivals on price, with input starting at $0.50 per million tokens. I unpack the benchmarks, pricing table, and market context (OpenAI, Anthropic, Google, GitHub Copilot) in my latest TechGlimmer deep dive: https://techglimmer.io/what-is-cursor-composer-2/
#Cursor #AI #FediDev #DeveloperTools #OpenSource #Coding #Anthropic #OpenAI
Cursor's Composer 2 Is the Cheapest Frontier Coding Model Yet

Cursor's Composer 2 beats Claude Opus 4.6 on benchmarks and costs just $0.50 per 1M tokens. Here's what developers need to know before switching.

techglimmer.io

So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.

You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Link—and PropertyValue is a schema.org type, not an Activity Streams 2.0 type.

The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.

I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.

What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.

#fedidev #ActivityPub #ActivityStreams #ActivityStreams2 #AS2 #PropertyValue

PropertyValue attachments serialize with invalid type for AS2 Object/Link validation · Issue #629 · fedify-dev/fedify

Description When Fedify serializes actor attachment properties containing PropertyValue items (used by Mastodon for profile metadata fields), the resulting JSON-LD uses schema:PropertyValue as the ...

GitHub

7/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of CALL Service actors associated with it) —

Maybe a call specific custom top-level attribute would be useful.

Maybe something like:

"call": [
{
"rel":"callpub",
"href":"https://videocalls.example/users/joeblow"
}
]

Or even:

"call": [
"href":"https://videocalls.example/users/joeblow"
]

.

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

6/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

Maybe a custom top-level attribute would be useful.

Maybe something like:

"service": [
{
"rel":"callpub",
"href":"https://videocalls.example/users/joeblow"
}
]

Although perhaps that is not much better than "attachment", if you just care about calls

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

5/

Continuing to look for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

I think "endpoints" would also be a poor choice, too. Again, the semantics are wrong, or at least lacking.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

4/

Looking for an alternative to "attachment" (for properly supporting an Actor specifying a list of Service actors associated with it) —

I think using "alsoKnownAs" or "sameAs" would be a poor choice. The semantics are wrong.

For example: a Service actor might represent my mobile phone (or software on it). My phone is not me. It is something I have.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

3/

But, what about the non- fall-back situation where software could properly support this (when an Actor specifies a list of Service actors associated with it)‽

I think some might say, put the associated Service actors in "attachment". And, semantically I think that would work with ActivityPub, but — I have a very strong dislike with putting everything in "attachment" (and "tag"). It makes parsing difficult.

So —

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

2/

Because most people wouldn't be able to add custom attributes or custom values to most Fediverse software (including Mastodon) —

Most supporting software would probably want to support a "PropertyValue" link in "attachment" field as a fall-back

For example:

"attachment": [
{
"type": "PropertyValue",
"name": "Video Calls (callpub)",
"value": "https://videocalls.example/users/joeblow"
}

But —

...

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

1/

AFAIK, there isn't a way for an ActivityPub Actor (such as a Person actor) to specify a list of Service actors associated with it.

...

For example, imagine that there is a Service actor that represents a way to make a video call to me.

And, for example, I have my Mastodon Person actor.

And, I want to let people know about it (and other Service actors associated with me).

How do I do that using AP, etc‽

...

#ActivityPub #ActivityStreams #AudioCall #Call #FediDev #Fediverse #VideoCall

Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.

https://github.com/fedify-dev/fedify/pull/631

#fedidev #ActivityPub #JSONLD

Add `http://joinmastodon.org/ns` to preloaded JSON-LD contexts by dahlia · Pull Request #631 · fedify-dev/fedify

Closes #630. http://joinmastodon.org/ns is used as the base URI for Mastodon’s custom JSON-LD terms like Emoji, discoverable, featured, blurhash, etc. However, this URL has never actually hosted a ...

GitHub