@maiyannah 1. I agree, adding new field into each "object" of the JSON message with UID in addition to each existing ID will be a good compromise preserving compatibility with old clients.
2. Regarding choice of the UID format/structure I strongly support a UID, which allows to identify easily the GNU Social instance that generated the UID. This way clients will be able to request, if necessary, additional information from the "Golden source". E.g. seeing the conversation ID:
"msg:208237@loadaverage.org" a client can automatically figure out that:
* this is GUID of a message/notice
* the message has this local Id (used by old clients and old !gnusocial instances): 208237 - a client may even query that instance for this local id (useful e.g. for conversations IDs... if new API is not supported by the instance...)
* the host/instance that created this message, is: loadaverage. org
No "hashes" as UIDs, please. Meaningless hashes will not allow to discover a !fediverse
?!