A test service

[evanp]

Could we build an online test service to test forward and backward discovery from the publisher and consumer side?

For consumers, we could have a server that provides a few dozen WF accounts that push the boundaries of this spec. Like: different origin for WF and AP ID, multiple self links, and so on.

For publishers, we could have an API and/or web page where you can submit a Webfinger address and get back the AP id, or vice versa. Its output could include errors for noncompliant behaviors or warnings for bad practices.

I think it's tough to test AP in its entirety, but I think this constrained profile provides an opportunity to make some progress and help developers with one of their first tasks with AP.

[tesaguri]

For consumers, I think it can be a static site (which implementers can easily host locally to their environment as well). Actually, I have written an nginx config for a static Activity Streams (well, not ActivityPub) and WebFinger server for a certain testing purpose before, like the following:

location /objects/ {
    types {
        'application/ld+json; profile="https://www.w3.org/ns/activitystreams"' jsonld;
    }
}

location = /.well-known/webfinger {
    try_files $uri /.well-known/webfinger/$arg_resource.jrd;
}

location /.well-known/webfinger/ {
    default_type application/jrd+json;
}

which can be included in a server block as a snippet. It should work by placing JRD documents at /.well-known/webfinger/acct:[email protected] and their corresponding actor documents at wherever under the /objects/ directory (with the .jsonld file extension). It should also be able to handle multiple hosts by adding multiple server blocks with appropriate server_name directives. I used Docker Compose to assign externally-accessible hostnames to the virtual tenants when I was playing with it, which I think would be a good fit for use cases like continuous integration.

For publishers, it can probably be a client program that implementers can locally run against their test servers.

[nightpool]

I do not think a static site has the ability to provide the right dynamic feedback that is necessary for real world debugging, for example, enforcing content type negotiation or the correct webfinger resource values.

…

On Mon, Apr 8, 2024, 7:09 AM Daiki Mizukami ***@***.***> wrote: For consumers, I think it can be a static site (which implementers can easily host locally to their environment as well). Actually, I have written an nginx config for a static Activity Streams (well, not ActivityPub) and WebFinger server for a certain testing purpose before, like the following: location /objects/ { types { 'application/ld+json; profile="https://www.w3.org/ns/activitystreams"' jsonld; }}location = /.well-known/webfinger { try_files $uri /.well-known/webfinger/$arg_resource.jrd;}location /.well-known/webfinger/ { default_type application/jrd+json;} which can be included in a server block as a snippet. It should work by placing JRD documents at ***@***.*** and their corresponding actor documents at wherever under the /objects/ directory (with the .jsonld file extension). It should also be able to handle multiple hosts by adding multiple server blocks with appropriate server_name directives. I used Docker Compose to assign externally-accessible hostnames to the virtual tenants when I was playing with it, which I think would be a good fit for use cases like continuous integration. For publishers, it can probably be a client program that implementers can locally run against their test servers. — Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV3RUQRHKZK2HER6X6DY4KCI7AVCNFSM6AAAAABF3N5L7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGU4DCNBUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[silverpill]

For publishers, we could have an API and/or web page where you can submit a Webfinger address and get back the AP id, or vice versa. Its output could include errors for noncompliant behaviors or warnings for bad practices.

@evanp https://verify.funfedi.dev can already test webfinger endpoints. I think it could also be a good foundation for consumer tests.

[evanp]

@evanp https://verify.funfedi.dev can already test webfinger endpoints. I think it could also be a good foundation for consumer tests.

Great!

[trwnh]

Should this be mentioned in the report? This is the only outstanding issue, and I'm not sure what the actionable item is here in terms of the report.