Se isso não for culpa do Discourse, levarei isso para o Mastodon. No entanto, a maioria das outras plataformas AP que tentei (que eu esperava que funcionassem) funcionaram.
Estou sentindo falta disso também. Sem isso, fica difícil ou impossível interagir com publicações federadas a menos que elas já estejam na sua linha do tempo.
@rokejulianlockhart, apenas por curiosidade, você já tentou com URLs de instâncias WordPress usando o plugin WP ActivityPub?
@rokejulianlockhart Para o seu ponto quando você criou este tópico, enquanto isso, https://meta.discourse.org/t/why-are-supposedly-activitypub-federated-discourse-threads-inaccessible-via-external-ap-clients/356997 não pode ser encontrado no Mastodon.
O Discourse AP precisa fazer o link url voltar para o id de alguma forma, preferencialmente via um redirecionamento em requisições com o cabeçalho de negociação de conteúdo Accept correto.
Consequentemente, definirei isso provisoriamente como um Bug. (Não consigo. Muito antigo.)
@icaria36, por favor, comente isso na Discussão do GitHub. Ter outra pessoa contestando a resposta confere mais credibilidade do que eu ser o intermediário.
Consultar o Discourse com isso resulta na resposta HTTP 400.
Omitir text/html;q=0.1 retorna um objeto ActivityStreams. Portanto, isso parece ser um bug com o Discourse, que parece retornar um 400 sempre que text/html faz parte dos tipos aceitos…
Não tenho certeza se este é um bug no Discourse. Respondi à questão no Mastodon. Cruzando postagens aqui para conveniência:
O motivo pelo qual retornamos um 400 nesse cenário é que a especificação do ActivityPub parece exigi-lo.
Requisições POST (por exemplo, para a caixa de entrada) DEVEM ser feitas com um Content-Type de application/ld+json; profile=“ActivityStreams 2.0 Terms” e requisições GET (veja também 3.2 Recuperando objetos) com um cabeçalho Accept de application/ld+json; profile=“ActivityStreams 2.0 Terms”
@ClearlyClaire É necessário adicionar text/html;q=0.1 ao cabeçalho Accept?