User stories with multiple users/roles

You seem to have already answered your own question:

Scenario: - There are two external user types - sellers and buyers.

From this, I infer that you have other roles that are considered internal (e.g. exhibition host, application admin, ...). You inherently listed buyer/seller as "the external user types", because that is what separates them from the other user roles (as per my inference).

Assuming my inference is correct, the correct approach here is to the define "external" and "internal" user roles (in a dictionary, if you don't already have one), and then you can refer to them where relevant.

AS AN external user
I WANT to view details (location/date/time) of upcoming exhibitions
SO THAT I can attend the exhibition.

To generalize the approach: if you need to refer to an abstract concept (in this case a grouping of roles), it becomes necessary to name the abstract concept so that you can then refer to it without worrying about it being understood.
Rather than trying to cleverly find a roundabout way to make it implicitly understood, keep it simple and make it explicitly understood (by explicitly defining the concept).

How you split the story depends on the sizing of the story. I see two possible options.

The first option, and where I would start, would be to write your story in a way that encompasses both user types. An example could be "As a potential exhibition attendee, I want to view the event details of upcoming exhibitions so that I can attend the exhibition." I would then use acceptance criteria to define who the potential exhibition attendees are, ideally mapped to specific users roles or personas. I would also use acceptance criteria to identify what, exactly, is meant by event details to clarify location and date and time. This is what I would initially present to the team.

Based on refinement of this, the team may come up with questions or concerns. If there is a lot of similarity between how the different user types are handled, maybe it makes sense to not split the story up. However, if there's unique work that needs to be done, maybe it makes more sense to split it up by user type or some other method to have smaller stories that can be delivered and reviewed.

As far as format, expressing the need as a user story, job story, use case doesn't matter so much. Your product manager or development team may find one format preferable. But that's a discussion for the team to ensure that the user need is expressed in a way that works for everyone involved. The same idea applies, though - the team can evaluate different ways to split up the story if it's necessary based on their evaluation of it.

The answer could be different in different individual cases, so let's look to the purpose of a user story for your answer.

The user story was created in response to robust specification documents that were meant to be cleanly handed off and avoid any need for further conversation or clarification. Instead, a user story was intended to give just enough information to facilitate a conversation between the team and the user. The answer to your question could be: "Which option facilitates a better conversation?"

If it really applies exactly the same for every attendee, then you can generalize. Alternatively, perhaps during refinement, you, the dev team, and stakeholders ask the question "How is this different if the user is the buyer? or the seller?"

And one last thing: the form of "As a, I want, So That" is not required for user stories. Would another format work better for your conversation?

Your case is that several roles share the same need and want the same feature:

• either use a more general role that covers the common interests (the advantage is that generalization encourage to think in broader terms and could thus identify other interested user populations)
• or simply enumerate the relevant roles, like you did it very pragmatically in your question (the advantage of remaining concrete is that you can rely on well identified personas and do not risk to invent some abstract role nobody can really identify with).

A more delicate case is when different users have different needs (sometimes conflicting) for the same feature. In practice:

• if the stories are complementary and not contradicting, handle them as any other stories: just keep 2 independent stories in the backlog (iterative refinement of the feature in due time).
• if the stories are contradicting, keep in mind that a user story is only a placeholder for a discussion. Resolve the conflict by discussing with both parties (together of possible) and agree on a common ground. Go back to the first case.
• if there is an overlap, merge them or make them independent using the same techniques as above. If one story appears to be not a real user story but a desire about how stories of other users should be, then consider making it an acceptance criteria.