<ocdtrekkie>
I think EtherCalc was going to use Redis too but my initial port used the JSON fallback and it stuck so far.
<ocdtrekkie>
Audrey mentioned possibility switching it back I think.
<zarvox>
this is software, so anything is possible! but migrating data across upgrades is probably a tad fraught.
natea has joined #sandstorm
<kenton>
we migrated etherpad from dirtydb to sqlite without too much trouble
<zarvox>
fair enough. You usually wind up having to support every historical data format to date in $CURRENT_RELEASE of the software though, or at least the migration code has to always be around.
<ocdtrekkie>
In the case of apps like Etherpad and EtherCalc though, the software already supported both data formats.
<ocdtrekkie>
So all you need is whatever script copies the data from one I to the other.
jadewang has quit [Ping timeout: 264 seconds]
jadewang has joined #sandstorm
citruspi has quit [K-Lined]
citruspi has joined #sandstorm
jadewang has quit [Read error: No route to host]
jadewang_ has joined #sandstorm
paroneayea has quit [Read error: Connection reset by peer]
<zarvox>
so I tried asking in #fedora-security about what they wanted to do, and the guy there asked me to email his @fedoraproject.org mail, and I did
<zarvox>
I even took the time to extract a minimal testcase and send that too
jadewang has quit [Read error: No route to host]
<zarvox>
and now it's been like 7 days since that initial contact, and nothing
<paulproteus>
I guess you should have gotten a CVE!
<paulproteus>
In fact --
<zarvox>
the fedora-security guy said that he was trying to get a CVE for it
jadewang has joined #sandstorm
<paulproteus>
We're going to have a list, one day, of "CVEs that Sandstorm was not vulnerable to."
<zarvox>
and that was why he hadn't filed a bugzilla ticket yet
<paulproteus>
Now we can have additionally a list of "CVEs Sandstorm successfully exploited by accident."
<paulproteus>
You should just request your own CVEs. Also oops I just said just.
ragesoss has quit [Remote host closed the connection]
<paulproteus>
Typically the thing to do is email this oss-sec at whateveritis.org email list and be like
<zarvox>
i,i now providing quality assurance for the Linux kernel
<paulproteus>
Hi can someone give me a CVE
<paulproteus>
and someone emails you off-list.
<zarvox>
oh, is that how it goes?
<zarvox>
I'd never done this before
<paulproteus>
It's like the good old days when you would join #cc and say "card plz" and then a bot PMs you a valid credit card number.
<zarvox>
What.
<paulproteus>
This makes lots of fun when cardsters join #cc on Freenode and are surprised to see the Creative Commons IRC channel doesn't have such a bot.
<paulproteus>
'One command, "!cclimit," even produces the spending limit on a particular card number, according to the report.'
<paulproteus>
'experienced fraudsters offered advice to newcomers, and stolen credit cards were given away freely to neophytes -- at least, in small amounts' so maybe if bots were helping, I can keep telling my story.
<zarvox>
oh paulproteus do you know why garplybot doesn't listen to my commands?
<paulproteus>
'If they weren't up for cracking a host personally, the "!cc" command dispensed a single stolen credit card number from a database.'
<paulproteus>
yes yes yes!
<paulproteus>
There we go.
<paulproteus>
Anyway. zarvox nope I don't particularly know.
paroneayea has quit [Read error: Connection reset by peer]
paroneayea has joined #sandstorm
<mquandalle>
The weave protocol that google introduced at i/o sounds pretty similar to capnp...
<kentonv>
how so?
<mquandalle>
it’s mostly my personal feeling because I haven't read any spec but it seems to be a way to define capability system interfaces
<kentonv>
I assume this is Nest's Weave? From what I can tell from google searches, it is how their devices set up an ad hoc network in the absence of wifi.
<kentonv>
but yeah, unclear without more documentation
<ocdtrekkie>
The difference is, Google will find a way to control the ever-living-crud out of any company who makes a device with it.
<ocdtrekkie>
And it's redundant with the eight protocols hardware manufacturers are already doing for IoT.
<kentonv>
IoT is a perfect use case for a capability protocol, but until capability-based thinking becomes common knowledge I'd be surprised to see a team like Nest actually produce such a thing.
<kentonv>
but I guess we'll see
<XgF>
Doesn't all of the stuff Google announced run on top of Linux? Sounds a bit heavyweight for most IOT applications...
<mquandalle>
Well IIRC they said the world “capability” several time during the i/o keynote
<mquandalle>
mostly about the android permission sytem
<kentonv>
mquandalle: people do say "capability" a lot when meaning something different. If they said "capability-based security" or "object capabilities" then maybe.
<mquandalle>
(and the fact that you will be able to add and remove permission to a given app)
<maurer>
mquandalle: If they were talking about the android permission system, they likely did not mean capability as capability
<XgF>
On the other hand, it's probably economically good for me if every damn lightbulb is running Linux :-)
<kentonv>
android permissions are an example of what we like to call crapabilities, much like Linux crapabilities; see https://lwn.net/Articles/641534/
<maurer>
>_> calling them crapabilities seems like a great way to get into an unproductive fight
<maurer>
(e.g. if you actually wanted to convince dbus or kernel devs that their model is wrong, calling the crapabilities will throw them on the defensive and make it difficult to truly win the argument, even if right)
<kentonv>
mostly we use the term within the Sandstorm team to disambiguate
<mquandalle>
That interesting because until now I was thinking that sandstorm powerbox would be similar to android permission system
<mquandalle>
And this is how I had explained it to some people
<XgF>
mquandalle: Instead of saying "This app can molest all of my contacts" you might say "This app can molest /this/ address book"
<kentonv>
mquandalle: in some sense they're similar but the powerbox is more powerful, in that a capability request from one app can be satisfied by the user's choice of other apps, rather than a singleton resource implemented by the system
<mquandalle>
or instead of "can access the network", it will be "can access this particular domain"
<XgF>
For an example of the problems with the Android permissions model, if I want my Facebook contacts to show up in my contact list (useful), I have to grant Facebook the ability to steal my contact list, because doing this requires Contacts Write and Contacts Read permissions
<mquandalle>
What kind of capabilities could an app like LibreBoard expose to others?
<XgF>
mquandalle: It might expose an API letting other apps manipulate your board, and it might consume the API of your calendar so you can put scheduled tasks in it (for example)
<kentonv>
you could design the LibreBoard API to have a capability for the board as a whole as well as capabilities for each column, each item, etc.
<kentonv>
so someone could grant some other app the ability to populate some input column without being able to manipulate the rest of the board
<kentonv>
not sure how likely that is to be useful in practice, of course
<ocdtrekkie>
XgF: Brillo is supposed to be an extremely lightweight Linux/Android-ish OS for IoT use.
<XgF>
ocdtrekkie: Right, but they described it as "stripped down Android" which to me still reads "Linux"
<kentonv>
isn't Linux relatively good at scaling down to small embedded systems?
<XgF>
kentonv: Right, but a Cortex-A5 is a big difference from, say, a Cortex-M0+
<mquandalle>
what about card attachments? Currently LibreBoard implements its own "upload a file to this card" feature. Would it make sense to define this notion of a card in the API, and then a third party application could attach a uploaded file with it?
<XgF>
That, or maybe even the other way around: you expose a "File API" which some other thing can view
<kentonv>
mquandalle: I think you'd do that the other way. The user would click "attach" on the card, and then it would make a powerbox request for a file (or arbitrary other capability, perhaps) to attach.
<mquandalle>
and in this case should libreboard see the actual file?
<mquandalle>
or it doesn't to?
<mquandalle>
need to
<XgF>
kentonv: Hmm, are we likely to see "transient" grains for viewer-type things?
<kentonv>
mquandalle: You can ask for whatever API (cap'n proto interface) you want, and the powerbox will present the user with a picker that only shows things implementing that API. So presumably there will be some "File" API with a read() method and you could request that.
<kentonv>
mquandalle: but it might be more fun in Sandstorm to ask for an arbitrary capability, and then the user can attach arbitrary objects from other apps, and then that object becomes available in the other board members' powerboxes for them to use in their other apps
<kentonv>
mquandalle: so I could, say, attach an Etherpad document to a card, and then others could open it
<ocdtrekkie>
XgF: I think it's likely. There may end up being a lot of types of programs people want to run in their private cloud service that aren't document-based.
<ocdtrekkie>
I totally expect to see apps that convert data and analyze data that might be accessed as a one-off or something.
<kentonv>
mquandalle: I mean, attach the document as an object reference, not a file, so when people open it, they get the original grain where they can collaborate with me
<kentonv>
XgF: quite possibly
<XgF>
kentonv: I guess there would still be some notion of document "ownership"? Original person can delete
<kentonv>
XgF: yes, when you attach a full-grain capability it would work much like sharing; you would be able to choose permissions, etc.
<kentonv>
XgF: basically it's like making a share link and putting it in the card, except at no point is there a magic-bits link that could leak
<XgF>
Hmm, would "attach by copying" be possible too (and in that case would the grain be a "child" of the board?)
<kentonv>
XgF: At some point we'll have an easy "make a copy of this grain" feature, which you could use to attach a copy, or alternatively you could attach the document read-only and other people could choose to make copies if they want to edit.
<XgF>
:)
<XgF>
I'm thinking that the ability to make sub-grains would be useful from a "not littering my userspace with lots of random bug report attachment grains" perspective
<mquandalle>
kentonv: and also I guess if you implement the API the way you want, you would be able to display more things on the card that just a text link, for example to display a miniature image (whether it is a file or an etherpad document)
<kentonv>
XgF: yeah, possibly. I've thought a little bit about it, though most of the thinking so far is around an app that wants to create sub-grains in order to take advantage of multiple machines in a cluster, so the sub-grains would have the same package. But it's not too hard to imagine an app which can create sub-grains that use different packages, and maybe that's useful for apps which compose other apps.
<XgF>
kentonv: I was thinking that then the "main UI" (where my grain list is today) would just become a "Directory" (or directory tree) grain, and maybe if I had some sort of CMS it would contain grains for "sub documents"
<kentonv>
mquandalle: yes, you could say that if the capability implements the HasIcon interface (regardless of what other interfaces it implements) then you'll display an icon from it.
<XgF>
I presume that Powerbox will support searching for caps by metrics other than just Interface->Interface, e.g. "File(mimetype=image/png)->UIView"?
<kentonv>
XgF: that would be pretty elegant. You could then easily share a whole directory full of grains with a collaborator, while not sharing everything.
<XgF>
kentonv: Yeah
<kentonv>
XgF: Yes, probably some sort of "tags" that can be arbitrarily defined.
<XgF>
The Powerbox sounds more and more like zope.component (which is seriously the best part of Zope)
<XgF>
Hmm. I now really want a capnp-js with window.postMessage transport :-)
<kentonv>
XgF: me too. :)
<kentonv>
in fact zarvox and I were talking about that just the other day. Although I don't think we'll have time to work on it very soon.
<kentonv>
but if someone builds it we will totally use it. :)
<XgF>
The only problem I have with the whole idea is that I dislike JS :P
<kentonv>
yeah, well, who actually likes JS? :)
<kentonv>
other than people who think async I/O is "bad ass rock star tech", and not something that's been used for 40 years.
<aldeka>
:/
<kentonv>
(I say this, while having used almost exclusively async I/O in Sansdtorm, and of course a lot of JS, much of which runs on Node.)
<maurer>
I mean, async IO isn't wrong, it's just not new.
<kentonv>
right
<maurer>
And also doesn't solve all problems
* maurer
glares at ocaml who keeps claiming asynchrony means they totally don't need real threads
<kentonv>
I think that async I/O is terrible, but threads are also terrible. Everything is terrible.
<maurer>
kentonv: Yeah, my beef with the "async IO is enough" folks is that if you have a server that is doing any kind of heavy compute ever, you can block all requests behind one slow request
<XgF>
kentonv: As someone who works on hardware, writing things as lots of state machines is also terrible :-)
<XgF>
Especially when all those state machines interconnect in 50 different places...
<kentonv>
hardware is a magic black box to me
<XgF>
Its' a scary (but fun) world where everything is parallel
natea has quit [Quit: natea]
<ocdtrekkie>
I am checking out the new users tab.
<ocdtrekkie>
Do I have to be not active for a bit before the last active field will show me there?
<ocdtrekkie>
Or is it not implemented yet?
<kentonv>
eh?
<kentonv>
it should update whenever you open a grain, I think
<ocdtrekkie>
Ah, I have to open a grain.
<ocdtrekkie>
I'm just in the shell.
natea has joined #sandstorm
natea has quit [Client Quit]
<kentonv>
yeah we count "active users" based on interaction with grains
natea has joined #sandstorm
natea has quit [Client Quit]
natea has joined #sandstorm
gopar has joined #sandstorm
keturn has quit [Ping timeout: 255 seconds]
keturn has joined #sandstorm
jadewang has quit [Remote host closed the connection]