torresjrjr(7) 0x85A5ADE2

RFC Nest – A simple, line-oriented data serialisation format

· Byron Torres

This is an informal request for comments to the world for a new file format called Nest, a simple, line-oriented data serialisation format.

Project page:


# Gemini Spacecraft On-Board Computer (OBC)

.host: aurelis-38
.type: Gemini Guidance Computer
	.frequency: 7.143 kHz
	.power:     26 V DC
	.weight:    26.75 kg

.reference system: barycentric celestial
.equinox: J2000.0 SOL

.systems enabled::
	- InternalGuidanceSystem
	#Attitude Control and Maneuver Electronics
	- ACME v9.0.1
	- HorizonSensors
	- TimeReferenceSystem TCB

	|Source Melchizedek.0294
	# southern circumpolar constellation
	|Approach β Hyi
	|	Ascension 00h 25m 45.07036s
	|	Declination –77° 15′ 15.2860″
	|	Distance 24.33ly

	# QEC adjusted
		.date: 3781
			|Cryogenic stasis interrupted.
			|The β Hyi system solar radiation has
			|unbalanced our infrared venting,
			|causing a 0.002° drift.
		.date: 2444
			|Our Pod 14 non-denominational coven voted to
			|cast a spell to help you on your way!


It’s reminiscent of YAML, but stubbornly simple like Gemini. It’s designed to be dead easy to implement and handle in terms of the Unix Philosophy.

It only stores strings within maps and sequences. There’s no “null”. Strings can be inline or multiline. As of the current revision of Nest, certain strings are invalid, namely when a multiline string doesn’t have a trailing newline character. This is something I’d like to reconcile.

I have had various spurs of thought for revisions or new syntaxes. You can see a few on the Fediverse.

This file format was primarily inspired by the NestedText project. I had made my own implementation of NestedText in Go, but a new version of the spec was release, which in my opinion deviated too greatly into needless complexity.

Please send in your thoughts and contributions in the comments.