Matt Dean

Not currently. But it looks like all the data is contained in `crosspost_parent_list`, which is just a list of non-enveloped Submissions. Shouldn't be too hard to get working.

Unless you or someone else wants to send a PR, probably not. Unfortunately I really just don't have the time to work on this project with work, class, and volunteering/extracurricular...

Not entirely, but I won't be able to put any work into it until finals are over.

I don't see any negatives here

Can you provide code that can reproduce this?

Are you using a SharedPreferencesTokenStore or another subclass of DeferredPersistentTokenStore? If so you might have forgotten to `load()` the tokens

DeferredPersistentTokenStore won't write non-significant PersistedAuthData objects. Maybe there's some faulty logic in there? - [Relevant test section](https://github.com/mattbdean/JRAW/blob/eeb94339c0fd501e6f0d88806d7bcca15523423f/lib/src/test/kotlin/net/dean/jraw/test/unit/DeferredPersistentStoreTest.kt#L60) - [Relevant source](https://github.com/mattbdean/JRAW/blob/eeb94339c0fd501e6f0d88806d7bcca15523423f/lib/src/main/kotlin/net/dean/jraw/oauth/DeferredPersistentTokenStore.kt#L44) - [`PersistedAuthData.simplify()`](https://github.com/mattbdean/JRAW/blob/eeb94339c0fd501e6f0d88806d7bcca15523423f/lib/src/main/java/net/dean/jraw/models/PersistedAuthData.java#L31)

Can you test it with the changes that closed #262?

Unfortunately right now there is not. I realize consumers might need to access properties not officially handled by JRAW and I plan on supporting it in v1.2.0 by forking [rharter/auto-value-moshi](https://github.com/rharter/auto-value-moshi)....

With Moshi, any properties not registered by the model are thrown away during deserialization. The fork would add the ability to store those would-be-discarded properties and then allow access to...