#goactivitypub — Public Fediverse posts

@stefan I'm sorry, but it's the same. You're blinded by the use case that mastodon enshrined in the fediverse.

Instances do not need to be ActivityPub servers, but clients.

If a low resource server handles only the ActivityPub logic and everyone can set one up, and then Mastodon, Pixelfed, Bookwyrm, etc are only applications that the same user can log in to, and uses to generate activities it'll work fully like a PDS.

This is, in fact, what I'm working towards with #GoActivityPub and its reference server implementation #FedBOX.

@stefan I'm sorry, but it's the same. You're blinded by the use case that mastodon enshrined in the fediverse.

Instances do not need to be ActivityPub servers, but clients.

If a low resource server handles only the ActivityPub logic and everyone can set one up, and then Mastodon, Pixelfed, Bookwyrm, etc are only applications that the same user can log in to, and uses to generate activities it'll work fully like a PDS.

This is, in fact, what I'm working towards with #GoActivityPub and its reference server implementation #FedBOX.

@stefan I'm sorry, but it's the same. You're blinded by the use case that mastodon enshrined in the fediverse.

Instances do not need to be ActivityPub servers, but clients.

If a low resource server handles only the ActivityPub logic and everyone can set one up, and then Mastodon, Pixelfed, Bookwyrm, etc are only applications that the same user can log in to, and uses to generate activities it'll work fully like a PDS.

This is, in fact, what I'm working towards with #GoActivityPub and its reference server implementation #FedBOX.

@stefan I'm sorry, but it's the same. You're blinded by the use case that mastodon enshrined in the fediverse.

Instances do not need to be ActivityPub servers, but clients.

If a low resource server handles only the ActivityPub logic and everyone can set one up, and then Mastodon, Pixelfed, Bookwyrm, etc are only applications that the same user can log in to, and uses to generate activities it'll work fully like a PDS.

This is, in fact, what I'm working towards with #GoActivityPub and its reference server implementation #FedBOX.

@stefan I'm sorry, but it's the same. You're blinded by the use case that mastodon enshrined in the fediverse.

Instances do not need to be ActivityPub servers, but clients.

If a low resource server handles only the ActivityPub logic and everyone can set one up, and then Mastodon, Pixelfed, Bookwyrm, etc are only applications that the same user can log in to, and uses to generate activities it'll work fully like a PDS.

This is, in fact, what I'm working towards with #GoActivityPub and its reference server implementation #FedBOX.

I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.

Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.

This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.

Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library. :goose_hacker:

#ActivityPubDev #fedidev #httpsig

I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.

Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.

This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.

Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library. :goose_hacker:

#ActivityPubDev #fedidev #httpsig

I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.

Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.

This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.

Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library. :goose_hacker:

#ActivityPubDev #fedidev #httpsig

I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.

Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.

This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.

Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library. :goose_hacker:

#ActivityPubDev #fedidev #httpsig

I've started working on generating RFC9421 compatible HTTP-Signatures in #GoActivityPub about a week and a half ago, but it felt more like a month.

Writing tests for the client module took the bulk of this time and it was a proper slog. We did manage to increase code coverage from under 20% to 80% plus.

This makes it a bit harder to migrate to a new API when the future version 1 of the library will be tagged, but the changes I have planned shouldn't be insurmountable.

Now I just need to implement the verification, and I'll be done with what is a very large milestone for the library. :goose_hacker:

#ActivityPubDev #fedidev #httpsig

@blainsmith yep, I have the #GoActivityPub wiki there: https://go-activitypub.federated.id

@blainsmith yep, I have the #GoActivityPub wiki there: https://go-activitypub.federated.id

@blainsmith yep, I have the #GoActivityPub wiki there: https://go-activitypub.federated.id

@blainsmith yep, I have the #GoActivityPub wiki there: https://go-activitypub.federated.id

@blainsmith yep, I have the #GoActivityPub wiki there: https://go-activitypub.federated.id

I have finally I made significant progress on this.

The final code looks like this:

https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199

For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)

Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.

I have finally I made significant progress on this.

The final code looks like this:

https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199

For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)

Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.

I have finally I made significant progress on this.

The final code looks like this:

https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199

For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)

Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.

I have finally I made significant progress on this.

The final code looks like this:

https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199

For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)

Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.

I have finally I made significant progress on this.

The final code looks like this:

https://github.com/go-ap/filters/blob/master/bytes_filter.go#L199

For a list of filters that #GoActivityPub uses, we generate two patterns for Quamina: one for a denormalized raw document, and one for normalized raw document (they usually are stored in a normalized form, where an Activity's object/actor properties are flattened to their IRIs, but we can't know which it is unless we unmarshall it, which we want to avoid)

Another improvement from my complain from 4 days ago is that I was regenerating the patterns and initializing quamina for every new document, instead of one time per collection load.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

One good thing of my extended sabatical from corporate employment is that while I'm working on #GoActivityPub there's so many things to do, that as soon as something interesting catches my eye, I can go explore it and learn a new thing that can be used, adapted or added to one of the components of the library or its adjacent tooling and applications.

Currently, I'm excited to replace the existing HTML sanitizer for TrustedTypes and setHTML in #ONI as they're finally making its way to Firefox.

I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub

Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.

Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. :goose_hacker:

#ActivityPub

I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub

Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.

Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. :goose_hacker:

#ActivityPub

I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub

Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.

Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. :goose_hacker:

#ActivityPub

I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub

Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.

Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. :goose_hacker:

#ActivityPub

I've started my exploration of using @timbray's Quamina project for saving some compute time in the filters module of #GoActivityPub

Currently the GoAP storage backends iterate over resources (usually stored as raw JSON bytes), unmarshal them into GoActivityPub object structs, and *only* then apply the custom filtering logic on those objects. Since the majority of the objects generally fail the filtering logic, all that JSON decoding is wasted compute time and makes things slower.

Ideally quamina will allow me to check the raw JSON payloads directly against the filters, streamlining the execution and speeding things up. :goose_hacker:

#ActivityPub

I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.

Most of them were due to minimal version being pre generics and pre interface{} -> any change.

I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.

Most of them were due to minimal version being pre generics and pre interface{} -> any change.

I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.

Most of them were due to minimal version being pre generics and pre interface{} -> any change.

I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.

Most of them were due to minimal version being pre generics and pre interface{} -> any change.

I ran the new go1.26 go fix tool on the #GoActivityPub modules and I was surprised how little improvements it had to suggest.

Most of them were due to minimal version being pre generics and pre interface{} -> any change.

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

I started adding #C2S #proxy_url support for #GoActivityPub services and it looks like it's easier than I imagined it initially.

On the server side, implementing the proxyURL handler doesn't need any new additions as it shares 90% code with other handlers that return #ActivityPub objects.

On the client side, I'm creating a new http.RoundTripper that can use the proxyURL transparently for the caller.

As a developer in your client code you only do a regular request for a remote URL, and the round-tripper handles the proxying part transparently if it has all the available bits: a server that supports proxyURL and a valid OAuth2 session towards that server.

My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.

I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.

https://go-activitypub.federated.id

My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.

I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.

https://go-activitypub.federated.id

My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.

I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.

https://go-activitypub.federated.id

My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.

I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.

https://go-activitypub.federated.id

My project that converts #SourceHut wiki repositories into static websites is finally getting to the point where it works quite well.

I've integrated it into my flow for the #GoActivityPub documentation and it looks decent (in my biased opinion), the docs themselves are not great, but I'll do another pass over them before we release a v1 of the library.

https://go-activitypub.federated.id

After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).

The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

#CIMD

After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).

The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

#CIMD

After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).

The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

#CIMD

After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).

The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

#CIMD

After much faffing about, I have implemented the dynamic #OAuth2 client creation for #GoActivityPub services using the Client ID Metadata Document[1] that's been proposed as a replacement(?) for RFC7591 (Dynamic Client Registration Protocol).

The changes are in both the Authorization service and in the BOX #ActivityPub client to server helper.

[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/

#CIMD