In reply to: https://crib.social/objects/5ce791b6-7a28-47b7-a8cb-80224f45a8c1
@taoeffect It is useful if you want a micro-blog account that is not tied to a single server / domain name.
@taoeffect It is useful if you want a micro-blog account that is not tied to a single server / domain name.
@taoeffect There is a caveat, of course. It can communicate with Mastodon and other Fediverse servers, but only a few of them are capable of distinguishing decentralized accounts from regular ones.
@silverpill @liaizon Which, fine, all resources from other places need to be restricted to prevent DoS attacks anyway.
@jeremiah ActivityPub relays can help with that
There are a couple of #ActivityPub projects that focus on providing the good tools that abstract away the complexities of wire-level network comms
You're talking to a developer of such project.
There is no "wire chaos", where did you get this idea from?
New post: Can we have a more “social” media?
https://profpatsch.de/essays/a-more-social-media
On advertising, the Fediverse, and what a more human social web could look like.
Special mentions: @smallcircles, @phnt, @happy-programming
@Profpatsch You need to create a new signature because the request target is changing. It is a part of a signature base, so the initial signature becomes invalid when the client follows a redirect.
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your SECURITY.md:
@smallcircles Fediverse is not like email because ActivityPub has many different message types. What kind of client API developers use is irrelevant.
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
@hongminhee +1 for formalizing the existing practice in a FEP.
PropertyValue is covered in FEP-fb2a, but it proposes an alternative representation which implementers must support:
https://codeberg.org/fediverse/fep/src/branch/main/fep/fb2a/fep-fb2a.md
@hongminhee It only includes the standard AP context. Do you have a workaround for that as well?
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
@hongminhee Can Fedify process this post?
@shinmera There is only a proposal:
@shinmera GoToSocial has a Mastodon migration tool, I see it’s archived though https://github.com/VyrCossont/slurp/
@shinmera when my main acces domain moved from mastodon to social I just changed the settings and made everything redirect there. Probably only broke the I stances that can't handle webfinger and the alias domain stuff thingy