@Edent
-
I discover your onepage activitypub application at https://shkspr.mobi/blog/2024/02/activitypub-server-in-a-single-file/
It is really a good start for me
But how would you adapt it with Ngnix server
All the logic is based on .htaccess but in Nginx it leads with all 404 pages
-
I discover your onepage activitypub application at https://shkspr.mobi/blog/2024/02/activitypub-server-in-a-single-file/
It is really a good start for me
But how would you adapt it with Ngnix server
All the logic is based on .htaccess but in Nginx it leads with all 404 pages
@tofeo take a look at https://gitlab.com/edent/activity-bot/-/blob/main/README_nginx.md?ref_type=heads
I don't use nginx, but that should help.
-
System moved this topic from General Discussion on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Yes, I think I like the idea of clients being able to store data on the server however they like. It reminds me of this description of ATProto that I found recently: https://overreacted.io/a-social-filesystem/
I guess my question is: once I store my custom stuff in custom places on my server, how do I publish this so other people can find?
And, object IDs are usually defined by the server. So how would it work to say "create a collection named XYZ and add this object to it"?
-
@benpate @silverpill in a client managed followers collection i would Add you to my followers just like fedi instances currently do silently. "but how can you prove--" yes exactly, how can current fedi prove anyone is a follower either? you need the Follow+Accept pair to both be live without an Undo on either, right? and that's what leads to the "follow state machine" on fedi that drifts out of sync and leads to private posts being leaked to removed followers (which you can't officially do!)
-
@benpate @silverpill @mariusor none of the IDs should have any semantics; from the outside, there is no distinction between a client managed or server managed collection. likes/shares/etc could be managed by a "client" like mastodon, or even a "default" one. it's not any more complex unless you want to vary the collection responses based on the request headers. for that you need a minimal dynamic layer with an access control policy of some sort. (WAC is the simplest, but ACP is more powerful)
-
I e*love* this idea- especially in principle. I say that because I’m having a hard time wrapping my head around this and how it would be used in practice.
Do you think you could post an example workflow (or three) to demonstrate how this would work?
I get that objects could be added to client-defined collections (very cool) but if object/collection IDs don’t have predefined semantics, how will I know where to look to get the data I need?
-
> The thanks was for your input with regards to collection management.
@silverpill of course, sorry for the misunderstanding. Doubly so, for forgetting Mitra is Rust, I remembered it to be Python. :D
And yes, the difficulty is indeed in massaging JSON-LD documents into strongly typed data that are meaningful for library consumers. However I've not despaired yet... there's light at the end of that boring tunnel. :P
-
@julian It looks simple on the surface, but in reality it is much more complicated than a non-generic server. In addition to activity transfer, generic server needs to maintain collections. First of all, a followers collection, which is often used as a delivery target. Then likes, shares etc. It needs to enforce permissions, to prevent actors on the same server from deleting each other posts.
This is doable if you only care about activities defined in ActivityPub. But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?
This is where duck typing (FEP-2277) and unified security model (FEP-fe34) become really handy. No matter what the client sends, you can figure out what it is (an object, an actor, or a collection), and enforce permissions.
-
@silverpill@mitra.social I find it curious that this needs to be spelled out in an FEP.
Isn't a generic AP server one that ingests anything and shoves it into the outbox... like a mail transfer agent?
... then delivers it dutifully?
I mean, sure, you can do stuff in between, like spam detection, blocklists, etc etc etc...
My quick read through of the FEP (and it was quick, because it was a short FEP :stuck_out_tongue:) seems to confirm this.
-
@silverpill lol, based on the "claims" at the begining, why do I feel like the "thanks" at the end should be in quotations?
Also I take umbrage with calling what I've been doing for the past 8 years as "being not difficult to build nor an interesting concept". I feel like you, and other developers having the benefit of dynamically typed programming languages, underestimate how that can be worked into robust APIs when you're limited by less versatile stacks.
