4 ms·

Show HN: Open Message Format – a compact, vendor-agnostic spec for messages

32 points by aayushwhiz 2y ago

aayushwhiz 2y ago
Open Message Format (OMF) is a specification for structuring message exchanges between users, servers, and large language models (LLMs). It defines an API contract and schema for the "message" object, which supports communication in conversational agents. OMF allows developers to work with different LLMs and tools without writing extra translation code.
lbotos 2y ago
Advice: Maybe consider the "comparison box" up higher as it's the easiest fastest way for a new reader to see current state. My first thought was "how many of the big players are compatible with this" and surprisingly, many are now. The second larger up hill battle you have is specs like this are usually driven by a company or some sort of consortium. Who are you in relation to these orgs to hope to influence/encourage such spec usage?
- aayushwhiz 2y ago
  Thank you so much for the feedback about the location of the comparison box, I have merged a change that moves it up higher in the readme.
- aayushwhiz 2y ago
  In response to the second part, this project is a part of the Open LLM Initiative, which also has projects like the Global LLM Challenge. We are also planning to push this project into a consortium once it gains some traction, and we are currently working with some tools so that they adopt this format.
rollulus 2y ago
I think it would be challenging to come up with a more ambiguous name.
- aayushwhiz 2y ago
  Hi, do you think it would be beneficial to specify that it is for LLM interaction within the name itself?
ianbicking 2y ago
Lots of broken links in the doc, though I guess the YAML file specifies everything: https://github.com/open-llm-initiative/open-message-format/blob/main/OMFspec.yml https://github.com/open-llm-initiative/open-message-format/b... The metadata tokens is a string [1]... that doesn't seem right. Request/response tokens generally need to be separated, as they are usually priced separately. It doesn't specify how the messages have to be arranged, if at all. But some providers force system/user/assistant/user... with user last. But strict requirements on message order seem to be going away, a sort of Postel's Law adaptation perhaps. Gemini has a way of basically doing text completion by leaving out the role [2]. But I suppose that's out of the standard. Parameters like top_p are very eclectic between providers, and so I suppose it makes sense to leave them out, but temperature is pretty universal. In general this looks like a codification of a minimal OpenAI GPT API, which is reasonable. It's become the de facto standard, and provider gateways all seem to translate to and from the OpenAI API. I think it would be easier to understand if the intro made it more clear that it's really trying to specify an emergent standard and isn't proposing something new. [1] https://github.com/open-llm-initiative/open-message-format/blob/main/OMFspec.yml#L133 https://github.com/open-llm-initiative/open-message-format/b... [2] https://ai.google.dev/gemini-api/docs/text-generation?lang=rest https://ai.google.dev/gemini-api/docs/text-generation?lang=r...
- un1imited 2y ago
  hey @ianbicking - thanks a lot for the feedback. I've merged a change to fix the links [1]. > The metadata tokens is a string [1]... that doesn't seem right. Request/response tokens generally need to be separated, as they are usually priced separately. For the metadata you are right. Request and response tokens are billed separately and should be captured accordingly. I've put a PR to address that [2] > It doesn't specify how the messages have to be arranged, if at all. But some providers force system/user/assistant/user... with user last. ... We do assume that last message in the array to be from user. But we are not forcing it at the moment. [1] https://github.com/open-llm-initiative/open-message-format/pull/1 https://github.com/open-llm-initiative/open-message-format/p... [2] https://github.com/open-llm-initiative/open-message-format/pull/2 https://github.com/open-llm-initiative/open-message-format/p...
FutureCrafter 2y ago
[dead]
ianburrell 2y ago
If these aren't generic messages, then I wouldn't use something as generic as Open Message Format. I would suggest qualifying the name. Open LLM Message Format, OLMF. Or LOMF. Or OLIMF. Something to qualify the scope and advertise what it is for.
- aayushwhiz 2y ago
  I see, thank you for the feedback, I will do a brainstorm on the name, I originally thought that open message format seemed somewhat catchy, but I can totally see how it is generic and not as descriptive as it should be.
deepsun 2y ago
Squat all Open-* names!
endofreach 2y ago
Couldn't get past the thoughts about the naming after reading the first paragraph... I propose a better name: Simple Message Spec (SMS)!

32 points by aayushwhiz 2y ago

Open Message Format (OMF) is a specification for structuring message exchanges between users, servers, and large language models (LLMs). It defines an API contract and schema for the "message" object, which supports communication in conversational agents. OMF allows developers to work with different LLMs and tools without writing extra translation code.

lbotos 2y ago

Advice: Maybe consider the "comparison box" up higher as it's the easiest fastest way for a new reader to see current state. My first thought was "how many of the big players are compatible with this" and surprisingly, many are now. The second larger up hill battle you have is specs like this are usually driven by a company or some sort of consortium. Who are you in relation to these orgs to hope to influence/encourage such spec usage?

aayushwhiz 2y ago
Thank you so much for the feedback about the location of the comparison box, I have merged a change that moves it up higher in the readme.
aayushwhiz 2y ago
In response to the second part, this project is a part of the Open LLM Initiative, which also has projects like the Global LLM Challenge. We are also planning to push this project into a consortium once it gains some traction, and we are currently working with some tools so that they adopt this format.

rollulus 2y ago

I think it would be challenging to come up with a more ambiguous name.

aayushwhiz 2y ago
Hi, do you think it would be beneficial to specify that it is for LLM interaction within the name itself?

ianbicking 2y ago

Lots of broken links in the doc, though I guess the YAML file specifies everything: https://github.com/open-llm-initiative/open-message-format/blob/main/OMFspec.yml https://github.com/open-llm-initiative/open-message-format/b... The metadata tokens is a string [1]... that doesn't seem right. Request/response tokens generally need to be separated, as they are usually priced separately. It doesn't specify how the messages have to be arranged, if at all. But some providers force system/user/assistant/user... with user last. But strict requirements on message order seem to be going away, a sort of Postel's Law adaptation perhaps. Gemini has a way of basically doing text completion by leaving out the role [2]. But I suppose that's out of the standard. Parameters like top_p are very eclectic between providers, and so I suppose it makes sense to leave them out, but temperature is pretty universal. In general this looks like a codification of a minimal OpenAI GPT API, which is reasonable. It's become the de facto standard, and provider gateways all seem to translate to and from the OpenAI API. I think it would be easier to understand if the intro made it more clear that it's really trying to specify an emergent standard and isn't proposing something new. [1] https://github.com/open-llm-initiative/open-message-format/blob/main/OMFspec.yml#L133 https://github.com/open-llm-initiative/open-message-format/b... [2] https://ai.google.dev/gemini-api/docs/text-generation?lang=rest https://ai.google.dev/gemini-api/docs/text-generation?lang=r...

un1imited 2y ago
hey @ianbicking - thanks a lot for the feedback. I've merged a change to fix the links [1]. > The metadata tokens is a string [1]... that doesn't seem right. Request/response tokens generally need to be separated, as they are usually priced separately. For the metadata you are right. Request and response tokens are billed separately and should be captured accordingly. I've put a PR to address that [2] > It doesn't specify how the messages have to be arranged, if at all. But some providers force system/user/assistant/user... with user last. ... We do assume that last message in the array to be from user. But we are not forcing it at the moment. [1] https://github.com/open-llm-initiative/open-message-format/pull/1 https://github.com/open-llm-initiative/open-message-format/p... [2] https://github.com/open-llm-initiative/open-message-format/pull/2 https://github.com/open-llm-initiative/open-message-format/p...

FutureCrafter 2y ago

[dead]

ianburrell 2y ago

If these aren't generic messages, then I wouldn't use something as generic as Open Message Format. I would suggest qualifying the name. Open LLM Message Format, OLMF. Or LOMF. Or OLIMF. Something to qualify the scope and advertise what it is for.

aayushwhiz 2y ago
I see, thank you for the feedback, I will do a brainstorm on the name, I originally thought that open message format seemed somewhat catchy, but I can totally see how it is generic and not as descriptive as it should be.

deepsun 2y ago

Squat all Open-* names!

endofreach 2y ago

Couldn't get past the thoughts about the naming after reading the first paragraph... I propose a better name: Simple Message Spec (SMS)!