Node-solid-server: when "test quota on write" fails, it should notify pod owner

[TallTed]

In catching up on a lot of discussion and updates, it seems that when the "test quota on write" fails it results in a notification to the attempting writer -- so if @kjetilk tries to write to @RubenVerborgh's INBOX and that write would exhaust quota, @kjetilk gets notified -- but @RubenVerborgh does not.

This is troublesome, as @kjetilk's best (and possibly only) way to inform @RubenVerborgh of this problem is via his inbox ... which is full. I think that this is a place where NSS might use @RubenVerborgh's email address to send such a notification without consuming further NSS-quota.

_Originally posted in https://github.com/solid/node-solid-server/issues/918#issuecomment-450062727_

[melvincarvalho]

@TallTed seems like this is a valid issue. Are there some docs on how the quota system works, to the level of detail of notifications? For example, if you have several inboxes where do notifications go?

First thought is that the sender will get a notification via HTTP if the quota is full (I think). If there's just the HTTP error then the notification system doesnt come into play. Another thought is that you can fill a quota with spam.

If we take the other approach of advising the target they could also get a lot of spam, say when they have diminishing space. Which in turn could feed through to email giving possibly a bunch of notifications. For example, Ive had machines go into infinite loops before, if that yielded a notification you could end up with filled inboxes, or even getting pods banned for spam, sometimes also pods pay for each mail sent (e.g. 1 cent).

One solution that worked well in the PHP solid server was that users had a little green bar in their header showing them how full their space was. This lead to users being trained into seeing how full their system was.

[TallTed]

@melvincarvalho - My earlier comments are not based on code review, just on the comments others made around the quota discussion.

"If you have several inboxes where do notifications go" -- since we're talking about exhausting quota on one inbox, I think notification goes to the email address associated with that inbox. If there are multiple email addresses associated with one inbox, things do get more complex, and maybe there should be user selection of where such server-generated notices should be sent.

My initial comment was based on a sender getting an HTTP fail because quota on the destination is full, which now tells the sender the inbox is full, but doesn't tell the receiver a/k/a the owner of the inbox (similar to a caller trying to leave a message in a full voicemail box), so the receiver doesn't know they need to increase their quota or delete some stuff (exactly what is deletable in the solid context? I own my data, so I store all my comments, but I exhaust my quota, so I delete my comments, so the bug on which I've been commenting no longer shows my comments, so they are no longer part of the bug history, so the bug isn't addressed to my satisfaction, so..... I wonder whether this has been considered/addressed anywhere yet?)

I think there must be some way of advising the owner of the target inbox that their quota is exhausted -- and such notice should not be sent more than _n_ times in _m_ time, perhaps tied to both time-passage and quota-consumption-reduction (so, if they delete stuff so quota is no longer exhausted, but a subsequent write again hits the limit, this is worth a new notice; but multiple attempts to write without intervening content deletion should not trigger multiple notices within some [configurable] time limit)....

Infinite loops and DOS attacks are always bad. All possible effort to prevent such loops should be made, but the possibility of such loops should not prevent implementation of important functionality -- else no-one would ever develop anything, because loops are always possible. So, the same writer attempting to write to the same inbox _n_ times in _m_ minutes should probably result in 1 alert, not _n._ The system trying to write a notice that quota is exhausted which write fails because quota is exhausted should not trigger another attempt to write a notice that quota is exhausted, etc.

Micropayments/microbilling (e.g., $0.01/email sent) to my knowledge remains pretty much a nightmare for all involved. At least, I'm not aware of any active system which puts these to good use.

A visual consumption indicator is always a good idea on quota-based systems. Little green "fillup" bars are helpful; explicit quantity numbers as mouseover helptext (or even as the visual) are good too (see Gmail and other implementations).

I think there will be more discussion on this.

[kjetilk]

Yeah, it is definitly a valid issue. Note, however, that the current quota system is a stopgap meant to serve a very specific use for a quota on less than 100 MB, or no quota at all. It was hard to implement anything sensible because there is no good way to persist anything beyond the OIDC subsystem or the owner's POD.

We really need to think of a better way, but I think it starts by introducing a good way to persist stuff like this in a performant way. I mean, it should be trivial, but in the current server, it doesn't seem to be.

[MasterJames]

I'd considering allow over-quota for alert emails about quota limits that occur before the actual limit. So some priority levels and early warnings sounds like a worthy idea to mention.