Prior Art and Streamtyped Issues

[GroveJay]

This project is amazing and I've enjoyed reading the code and the in-depth blog about reverse-engineering the typedstream binary format!

I'm working on a project requiring reading messages from iMessage's database and my inspiration/prior art calls Objective-C to "parse" the attributedBody field. Your proved it's feasible without that and I completed a prototype based on imessage-database/src/util/typedstream/parser.rs.

I noticed some issues when decoding test messages I crafted¹. This led me to do a deeper dive on the typedstream handling especially how object nesting could be handled.

I then discovered another project just parsing typedstream data, python-typedstream. While I much prefer your code, python-typedstream seems to decode while maintaining object nesting.

All this to say reworking the typedstream handling could be worth it in order to handle object nesting thereby more easily translating Archivables into BubbleComponents.

I'd take a pass at it myself, but I'm only barely able to read rust code and I'm not huge on how python-typedstream is structured.

Footnotes

1. The issue stems from code parsing attribute dictionaries assuming a dictionary could only be a link or styles but not both. I can provide the exact test attributedBody if desired. ↩

[ReagentX]

imessage-exporter should support that; it's probably a small adjustment to the BubbleComponent assembler and not the typedstream deserializer, which does in fact retain the class hierarchy and understand nested objects.

If you can send me a sample file or how the message was generated I will take a look.

[GroveJay]

The hierarchy may not be meaningful when a single NSAttributedString is the only value encoded in the typedstream, that seems likely.
It is encoded in the stream though as each object has an end marker and all objects between the start of the object and that end are its children.

python-typedstream parses the object hierarchy:

"""Iteratively read an object from the typedstream,
including all of its contents and the end of object marker.

I don't love the way it's implemented (yielding a stream of events seems more complicated than it's worth). Testing/debugging showed each object ending and coming out with all of its child objects, making iterating through them simple and intuitively correct.

This doesn't impact the issue I mentioned, that was just my reason for diving deeper into the parser to understand it better and I thought my findings interesting to discuss.

I do have another unicode/emoji attribute related issue I'll file an actual issue for, but it seems like a nightmare to deal with 😅

[ReagentX]

That is not how python-typedstream works. It defines a ton of specific, rote routines (e.x., for NSURL, which is part of what your sample touches) for assembling specific Foundation types. It does not retain any hierarchy from the stream, rather it constructs Python imitations of Foundation types from a pre-built library of known types. It does this by iterating over the stream and reading the decoded class, then looks it up in a table that maps that class to the defined routine that builds the "hierarchy".

Again, the hierarchy is not included in the stream in any way–which is why the libraries you mentioned do not support it. You can assemble the hierarchy from the decoded data, which is what imessage-exporter does. The issue in this thread was caused by the BubbleComponent assembler not permitting overlapping components (and the html/txt representation logic from rendering said overlapping styles), not the supposed lack of hierarchy data.

[GroveJay]

I shouldn't have included the word "Issues" in the thread subject 😞

You're right that it parses objects based on the known types. And it determines if the object is correctly closed based on the EndObject stream event. In some cases that results in generic nested objects (which have contents). I've been interpreting the value of the EndObject as directly indicating which objects are within others, but it seems to only be used as a final check in python-typedstream in most cases?

[ReagentX]

I'm not sure what you are referring to. imessage-exporter supports field data. It is present in the stream and yielded when appropriate.

The BeginObject and EndObject constructs are created in that library and are not part of the typedstream spec. If you need help with that library, you should open a ticket there; I don't provide support for it.

[GroveJay]

I'm not trying to raise a specific issue or get help with that library, I just thought it'd be interesting to compare a different (more comprehensive but uglier imo) deserializer that I thought had some merits vs this library.

I was super confused with some parts of the code here (as I mentioned in my first reply), got stuck on an edge case, and ended up thinking both deserializers were neat.

Thanks for discussing it! Hopefully I can show my garbage golang version in the future 😄