Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I'd suggest taking a look at Movim: https://movim.eu/
It takes an appropriately set up xmpp server and essentially reproduces a social network. Microblogs, groups, and chat. Implements OMEMO and the like if memory serves. It is a great platform and just as compelling as Discord IMO.
I've tried to set up some Matrix projects. The Client-Server API is easy to work with, but as soon as encryption is involved, things start getting messy. Many libraries have a hard time working right with E2EE enabled, because suddenly you need to keep track of all manner of things that aren't always documented well.
I tried to hack E2EE in by using Pantalaimon [0] but running that on a server with the necessary management capabilities is very tricky and doesn't do cross signing, so I've come to the conclusion that it's effectively useless for my use cases.
Every now and then I check back on the current state of E2EE in libraries and it does seem to be improving. Hopefully the entire process becomes easier next time I get the time to work on my proof of concept code.
[0]: https://github.com/matrix-org/pantalaimon
Agreed. I wish json5 had become, or becomes the standard.
https://json5.org/
I saw this earlier as hoytech's Github was on HN front page: https://github.com/hoytech/serialipedia
Curious how would HN readers rate YAML vs CBOR.
TinyCBOR has a json2cbor utility (uses cjson) I have been testing.
> does it always use UTF8 or does it break the standard?
It always uses UTF8, or it is invalid JSON and MUST NOT be parsed. For the same argument against XML, you could argue whether it actually honours the encoding field (i've found many cases where things lie in the encoding field, and still parse fine by XML parsers)
> Which version of the JSON Schema does it use?
Quite literally the only one I have ever seen in use, ever, is JSON Schema[0].
> Is it using a schema at all?
Most often, no.
> What happens when "$ref" appears in the content body?
Nothing? JSON doesn't have lookups. There is no way to do lookups in JSON. If you do otherwise, you do not have JSON anymore.
> How should I deal with duplicate keys?
This is an actual, real issue with JSON.
XML is a terrible format. It's filled to the brim with footgun features like entity expansion (only ever used to DOS servers), no data types (everything is a string, your parser just needs to know better), no meaningful reason to have both attributes and content, ambiguity between an array of one element and an element, etc. etc. etc.
[0]: https://json-schema.org/
how about like this
https://github.com/harmony-development/protocol
?