@dpwiz

1. Create official `aeson-extras` package and put in an AesonBS newtype wrapper with `toJSON = toJSON . UTF8.toString . Base64.encode . unByteString` and `parseJSON x = parseJSON x >>= either fail $ (return . AesonBS) . Base64.decode . UTF8.fromString`.

2. Create official `aeson-bytestrings` package and write an opt-in instance for ByteStrings there.

3. Promote these two packages in documentation, blog posts and related GitHub / mailing list issues.

I mean, if we look at the history of `aeson` we'll see that they used to have *some* (broken) instance for ByteString, but then removed it.

If I was an `aeson` developer, I would simply have the instance I described previously in the library itself, because I think it's generic enough to capture the *nature* of what it means to serialise an arbitrary ByteString to JSON and I would ask people who need different radixes like Bitcoin's Base58 or hex to opt-out and use a wrapper. But I understand that it's a little bit too hot of a take.

Also it's a very supreficial set of ideas, maybe there's an actual smart approach with open systems like type families, but I feel like it'd require to refactor too much, since aeson for the end user is represented by just two typeclasses.

@jonn I'd totally agree with you and even support the default behavior you propose...

But there a many who still use ByteString.Char8 for all kinds of textual data and who'll start to whine that the instance is broken and clashes with their own orphan hack. Aeson maintainers then would have to deal with a steady trickle of "my perfectly fine latin-1 strings got mangled".

A deliberate lack of instance can be a speed bump to slow down and consider the situation.

@dpwiz I agree that lack of instance is the second best idea.

I'm not sure about `ByteString.Char8` argument, to be honest. In my experience, people who are using ASCII / Latin-1 are normally not the people who deal with JSON. It's normally telecom crowd, etc, for whom JSON is "too expensive" of a format.