#fedbox — 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.

Well, I've just fixed an annoying CI failure for the new integration tests for #FedBOX.

This one had been driving me mad for at least two months, but it was never a super high priority, as they're not a load bearing part of the test suite yet.

It was all due to a too small timeout on the container initialization. Sheesh...

Well, I've just fixed an annoying CI failure for the new integration tests for #FedBOX.

This one had been driving me mad for at least two months, but it was never a super high priority, as they're not a load bearing part of the test suite yet.

It was all due to a too small timeout on the container initialization. Sheesh...

Well, I've just fixed an annoying CI failure for the new integration tests for #FedBOX.

This one had been driving me mad for at least two months, but it was never a super high priority, as they're not a load bearing part of the test suite yet.

It was all due to a too small timeout on the container initialization. Sheesh...

Well, I've just fixed an annoying CI failure for the new integration tests for #FedBOX.

This one had been driving me mad for at least two months, but it was never a super high priority, as they're not a load bearing part of the test suite yet.

It was all due to a too small timeout on the container initialization. Sheesh...

Well, I've just fixed an annoying CI failure for the new integration tests for #FedBOX.

This one had been driving me mad for at least two months, but it was never a super high priority, as they're not a load bearing part of the test suite yet.

It was all due to a too small timeout on the container initialization. Sheesh...

Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.

Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...

Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.

Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...

Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.

Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...

Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.

Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...

Resurrected the nodeinfo helper service for the #FedBOX generic #ActivityPub service.

Hopefully this will lead to better integration with other federated services, but I find very little practical use for these hamfisted .well-known APIs integrated into the fediverse...

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

Due to a little impulse from @steve I've improved the documentation for #FedBOX and its adjacent #OAuth2 authorization server.

Currently it lives here: https://mariusor.srht.site/apps/fedbox/authorize/

Due to a little impulse from @steve I've improved the documentation for #FedBOX and its adjacent #OAuth2 authorization server.

Currently it lives here: https://mariusor.srht.site/apps/fedbox/authorize/

Due to a little impulse from @steve I've improved the documentation for #FedBOX and its adjacent #OAuth2 authorization server.

Currently it lives here: https://mariusor.srht.site/apps/fedbox/authorize/

Due to a little impulse from @steve I've improved the documentation for #FedBOX and its adjacent #OAuth2 authorization server.

Currently it lives here: https://mariusor.srht.site/apps/fedbox/authorize/

Due to a little impulse from @steve I've improved the documentation for #FedBOX and its adjacent #OAuth2 authorization server.

Currently it lives here: https://mariusor.srht.site/apps/fedbox/authorize/

RE: https://metalhead.club/@mariusor/116058273246682831

Thanks Marius! It was awesome to work with you on the logo! #FedBOX #ActivityPub

RE: https://metalhead.club/@mariusor/116058273246682831

Thanks Marius! It was awesome to work with you on the logo! #FedBOX #ActivityPub

RE: https://metalhead.club/@mariusor/116058273246682831

Thanks Marius! It was awesome to work with you on the logo! #FedBOX #ActivityPub

RE: https://metalhead.club/@mariusor/116058273246682831

Thanks Marius! It was awesome to work with you on the logo! #FedBOX #ActivityPub

RE: https://metalhead.club/@mariusor/116058273246682831

Thanks Marius! It was awesome to work with you on the logo! #FedBOX #ActivityPub

@andycarolan did it again and now #FedBOX, the generic #ActivityPub server, has a fresh of the press logo. :) Thank you Andy! 🥳

https://mariusor.srht.site/fedbox/

@andycarolan did it again and now #FedBOX, the generic #ActivityPub server, has a fresh of the press logo. :) Thank you Andy! 🥳

https://mariusor.srht.site/fedbox/

@andycarolan did it again and now #FedBOX, the generic #ActivityPub server, has a fresh of the press logo. :) Thank you Andy! 🥳

https://mariusor.srht.site/fedbox/

@andycarolan did it again and now #FedBOX, the generic #ActivityPub server, has a fresh of the press logo. :) Thank you Andy! 🥳

https://mariusor.srht.site/fedbox/

@andycarolan did it again and now #FedBOX, the generic #ActivityPub server, has a fresh of the press logo. :) Thank you Andy! 🥳

https://mariusor.srht.site/fedbox/

✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

✅ proxyUrl for #FedBOX on the server side and for #BOX on the client side.

Now I have to port the server bits which (like I said previously) are quite simple to #ONI, where it's more important to have them for me personally.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

@steve in #FedBOX I'm using the instance actor's regular inbox as a sharedInbox for the others.

I'm not sure in which way you're thinking it can help with federated vs. local timeline though, as the simplest logic to do that (IMHO) is to verify the activities' actors if they belong to the same instance as the actor that operates the "client". And for that it does not matter where they've been received.

And, in my experience, building timelines in clients can't really be done at viewing time due to inherent slowness in the AP fetches required. The clients need to buffer the collections locally and then they can apply whatever logic on top.

@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.

Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.

@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.

Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.

@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.

Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.

@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.

Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.

@hongminhee in #FedBOX and #GoActivityPub there's a cascading of behaviour for each ActivityPub object type, so you can call code on a Person/Group/etc, making the assumption that it has the more limited shape of a regular Object.

Since Go doesn't have more fancy types of polymorphism, I had to use some very ugly work arounds to be able to make this work. :( Sometimes I wish I was still working on a more powerful typed language, or a dynamic typed one.