Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

8.9K
active users

hachyderm.io: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

Hrefna (DHC)

While I don't want to get into until some questions on governance are answered (and I'd rather something like AP), there is a _lot_ to like here and a lot of things I think we'd be _extremely_ foolish not to use as concepts as we look to the future of .

Going into some of the specific things I like a lot here that are simply not possible* in AP today…

(* yes yes it is possible to conceive of how to do it in AP in a completely non-interoperable way, you're very smart)

1/

Lexicon A schema-driven interoperability framework
Lexicon is not RDF. While RDF is effective at describing data, it is not ideal for enforcing schemas. Lexicon is easier to use because it doesn't need the generality that RDF provides. In fact, Lexicon's schemas enable code-generation with types and validation, which makes life much easier!
Security and Privacy Considerations# There are a number of resource-consumption attacks possible when parsing untrusted CBOR content. It is recommended to use a library that automatically protects against huge allocations, deep nesting, invalid references, etc. This is particularly important for libraries implemented in languages without strong memory safety, such as C and C++. Note that high-level languages frequently wrap parsers written in lower-level languages.
Account portability# We assume that a Personal Data Server may fail at any time, either by going offline in its entirety, or by ceasing service for specific users. The goal of the AT Protocol is to ensure that a user can migrate their account to a new PDS without the server's involvement.
Dec 14, 2023, 05:57 PM·Public
5boosts·12favorites
Public
Helge

Code generation is really a missed chance for the Fediverse. I commented somewhere that verified credentials are simpler than HTTP signatures, as one doesn't need to write any parsers or serializers. One can just use the built-in ones.

One should apply the same perspective to the objects being exchanged: Can I design my protocol in a way that people don't have to write any custom parsers?

That people don't want to write code seems such an obvious insight.

Public
Helge

Just to give an example. @hrefna just liked and shared this post.

The Like activity contains the keys @context, actor, id, object, type. The Announce activity contains @context, actor, cc, id, object, published, to, type.

While I can somewhat understand cc being different, as one might not want to send the Like activity to one's followers. The rest make little sense to me. They create just another hurdle if one wants to implement ActivityPub.

It would be easy to finger point at Mastodon away from ActivityPub here. I think that trying to keep this stuff uniform (and thus easy to implement) is a task of the protocol and not the individual implementers.

Public
bryan newbold

@hrefna w/r/t governance, the current plan is to bring the core protocol to the IETF this year. they won't necessarily take it (would probably be a WG-level effort), but timing is tricky and I don't think we've waited too long so far.

the Lexicon namespacing system provides flexible governance over application Lexicons; that should be flexible to many governance patterns.

how com.atproto.* will work is vague. and there are some details around extensions of 3rd party lexicons to dig in to.

ExploreLive feeds
About