dograt has quit [Read error: Connection reset by peer]
harish has quit [Ping timeout: 256 seconds]
neynah has joined #sandstorm
kentonv has joined #sandstorm
isd has quit [Read error: Connection reset by peer]
isd has joined #sandstorm
samba_ has joined #sandstorm
isd has quit [Ping timeout: 240 seconds]
harish has joined #sandstorm
samba_ has quit [Ping timeout: 260 seconds]
<mnutt_>
it turns out AbiWord can work headlessly, is much less complex, and is likely much smaller. do we think it's worth losing davros's xls/ppt preview support for that?
<kentonv>
mnutt_, my experience with Etherpad's use of AbiWord for import/export is that it's pretty awful.
<kentonv>
like, the Debian package would just crash, because they hadn't merged some two-year-old bug fix, or something. But when I fixed that the quality of the output was just really bad.
<mnutt_>
ah, that's too bad but not all that surprising I guess.
<kentonv>
my impression was that it is under-maintained in general, although it's possible I just had a particularly bad experience
<mnutt_>
I guess the question being whether we're going for "I need to quickly see what's in this document" or "I want to be able to print a reasonably good looking copy of this from the web"
<mnutt_>
libreoffice's html output is decent and perfectly fine for the former, but still falls a bit short on the latter
<kentonv>
out of curiosity have you looked at things like pandoc and mammoth? Are they good?
<mnutt_>
I haven't, I'll take a look at those
<kentonv>
mnutt_, both are libraries and have npm packages, so seems like they'd be lighter-weight than libreoffice. But, no idea about quality.
<kentonv>
I guess pandoc is still 20MB
<mnutt_>
I wouldn't be surprised if it comes down a little bit in packing?
<kentonv>
wow, mostly written in Haskell
<kentonv>
yeah maybe
<kentonv>
ppt is not listed as a supported format though. :/
<mnutt_>
regarding document support...I don't personally have any need for much other than docx, though pptx and xlsx would be sorta nice for work stuff
<kentonv>
yeah I can see a reasonable argument for only going with document formats for now, and wait for add-ons before trying to support exotic stuff
jemc has joined #sandstorm
<digitalcircuit>
Could document previewing be implemented as a sub-grain of sorts, allowing you to replace the previewing backend? It sounds like a moderate bit of work...
<digitalcircuit>
It could defend against document exploits affecting the whole Davros instance though.
jemc has quit [Ping timeout: 246 seconds]
<kentonv>
digitalcircuit, I addressed this a bit on sandstorm-dev. It's conceivable but doesn't fit into any currently-planned UX model as to how this would be set up.
<digitalcircuit>
kentonv, noted! I didn't realize that channel existed, either.
<kentonv>
digitalcircuit, sandstorm-dev is the mailing list
mnutt_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
harish has joined #sandstorm
ShalokShalom has quit [Ping timeout: 264 seconds]
ShalokShalom_ has joined #sandstorm
xet7 has quit [Ping timeout: 240 seconds]
xet7 has joined #sandstorm
ShalokShalom_ has quit [Ping timeout: 240 seconds]
ShalokShalom has joined #sandstorm
GeneralP has joined #sandstorm
GeneralP_ has quit [Ping timeout: 240 seconds]
afuentes has joined #sandstorm
tobald has joined #sandstorm
ShalokShalom has quit [Read error: Connection reset by peer]
ShalokShalom has joined #sandstorm
ceiphas has joined #sandstorm
<ceiphas>
i have a huge problem here.... we have (had) a ethercalc sheet in sandstorm that had other values in a field displayed than what was calculated. i tried to restart the app, and now all data is gone completely
ShalokShalom has quit [Read error: Connection reset by peer]
ShalokShalom has joined #sandstorm
bodisiw has joined #sandstorm
jemc has joined #sandstorm
FredFredFred_ has joined #sandstorm
FredFredFred has quit [Ping timeout: 260 seconds]
mnutt_ has joined #sandstorm
ocdtr_web has joined #sandstorm
ShalokShalom has quit [Read error: Connection reset by peer]
<ocdtr_web>
ceiphas: It may be worth downloading a backup and seeing if you can find the data in the dump.json file that you should find in there.
ShalokShalom has joined #sandstorm
<ceiphas>
ocdtr_web: the dump.json was nearly empty afterwards, surely it was full before
mnutt_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrdomino>
hey kentonv, when would be good to hash out the background API?
<ocdtr_web>
ceiphas: My guess is if the data is not in dump.json and you don't have backups, than there is not much that can be done. Unless there's some other log data in the grain backup that is useful somehow.
<ocdtr_web>
I am a fanatically strong supporter of good backups.
<ocdtr_web>
mrdomino: Sidenote, I am super excited someone wants to work on that.
<mrdomino>
:)
mnutt_ has joined #sandstorm
mnutt_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TimMc>
ocdtr_web: That raises an interesting question. If I run a Sandstorm server for a group of friends, inevitably data loss will occur in an app and someone will ask me for a backup version of it. There's no good way to arrange for that, right?
<TimMc>
Extracting a single grain backup from a full server backup sounds... dubious.
<ocdtr_web>
TimMc: If you have good backup software, this is not hard. (I restore single-deleted files and folders at work regularly.)
<TimMc>
Oh, I thought grains used encrypted storage.
<ocdtr_web>
I am less concerned about backups for people running their own servers (because I consider server backup a solved problem), as I am about the present inability for Sandstorm users to easily make a backup of all their own grains.
<ocdtr_web>
Grains do not presently use encrypted storage.
<TimMc>
ahhh, ok
<ocdtr_web>
But presumably, even if they did, the user's credentials would be valid to decrypt them even if restored from a backup.
<TimMc>
Well, that simplifies that.
<TimMc>
True, and presumably the encryption key would not change within the time interval of "whoops" to recovery. (I was worried DB lookups would also be required.)
<ocdtr_web>
What would make backing up and restoring a encrypted grain drastically harder than an unencrypted grain? Other than the fact that file deduplication would not be effective?
<TimMc>
Depends on how clever the storage format is, doesn't it? :-P
<ocdtr_web>
I guess I don't really see a likelihood of encryption keys on existing grains being rotated regularly.
<TimMc>
*nod*
<ocdtr_web>
"clever" is another word for overengineered in many contexts. ;)
<ocdtr_web>
Generally, I think Kenton has leaned towards the simply/standard/effective option, unless there's a really good security reason for getting complicated (like the whole wildcard host thing).
<ocdtr_web>
If each grain has it's own encryption key, I'd think you'd really only need to rotate them somehow if the way you were storing those keys got botched pretty badly.
mnutt_ has joined #sandstorm
<mrdomino>
hmm, it'd be nice to have a way to transfer ownership of grains. the specific thing i want that for is to have "can take a backup" privileges on grains owned by other people though, so maybe there's a better way
<mrdomino>
(i'm also thinking about what happens when someone leaves an organization -- maybe something in the admin interface would be good)
<ocdtr_web>
mrdomino: I think that's been one of nolan_d's top requests. Ownership transfer.
<ocdtr_web>
One of mine has been the ability to share like cloning rights. To where you could make a complete copy of the grain. Which is a serious level permission because the grain may have non-visible secrets and stuff in the data inside. Or history people think is deleted in logs.
<mrdomino>
yeah
<ocdtr_web>
Presumably, if one could be given permission to make copies of a grain, they could be permitted to make backups of it as well.
neynah has joined #sandstorm
bodisiw has quit [Quit: This computer has gone to sleep]
bodisiw has joined #sandstorm
bodisiw has quit [Remote host closed the connection]