Bug Report: Handling PDS service endpoint in bluesky_chat

[lukehmcc]

I was trying to get chat features working in my flutter app and it wasn't as seamless as I thought it would be. Basically, I thought I could just initiate a BlueskyChat session and use it for all the endpoints without issue like the main Bluesky client. But to have chat features work properly, I have to specify my PDS service endpoint which is a tad complicated. I also have to know to specify the correct headers which I didn't realize until I asked around on the API discord server. Here is the code I used below:

final session = await createSession(
    identifier: user,
    password: password,
  );

  Bluesky blueskySession = Bluesky.fromSession(
    session.data,
  );
  did = session.data.did;

  Map<String, String> chatHeader = {
    "Atproto-Proxy": "did:web:api.bsky.chat#bsky_chat",
  };

  final plcClient = plc.PLC();
  final didDoc = await plcClient.findDocument(
    did: did!,
  );
  final serviceEndpoint =
      Uri.parse(didDoc.data.service.first.serviceEndpoint).host;

  BlueskyChat blueskyChatSession = BlueskyChat.fromSession(session.data,
      headers: chatHeader, service: serviceEndpoint);

It really isn't that complicated in retrospect, but the bluesky_chat would be much easier to use if this was done for you.

[myConsciousness]

Hi @lukehmcc, thanks for your feedback!

I think the difficulty would be that no means is provided to identify the service endpoints when using the chat service. And Atproto-Proxy header should also be fixed and set at least when using chat.

I would add a function to easily retrieve the service endpoint like getServiceEndpoint and set the proxy header internally with a const value.

btw I'm also considering integrating the bluesky_chat package into the bluesky package. I thought these should be separate packages since they have different Lexicon host names like app.bsky and chat.bsky, but it would be more seamless if they were integrated.

[lukehmcc]

Can you not use a PLC resolver to find the endpoint?

[myConsciousness]

@lukehmcc

Of course we can use the PLC endpoint directly, but I feel the presence of the PLC should not inherently be made aware to the client implementer.

Also even if we need PLC features, it should be implemented as an xrpc endpoint in atproto. For example I think you can get did document from Session object returned by .createSession :)

[myConsciousness]

And look at this code:

Future<void> main(List<String> args) async {
  final session = await createSession(
    identifier: io.Platform.environment['BLUESKY_IDENTIFIER']!,
    password: io.Platform.environment['BLUESKY_PASSWORD']!,
  );

  print(session.data.didDoc); // => DID Document from PLC
  print(session.data.didDoc?['service'].first['serviceEndpoint']); // => PDS host
}

[myConsciousness]

@lukehmcc

I fixed about this issue in #1544.

Please try bumping the package version in your app, then the process of searching for services and adding proxy headers is no longer necessary :)