OpenSprites-next
OpenSprites-next copied to clipboard
OpenSprites
Messages/Alerts
Just like scratch. No idea how we should implement this: @MegaApuTurkUltra ideas? I feel like simply pushing to db.User.find(...).messages won't be robust enough
Well we can have a message queue under the user schema. Different events would generate messages for that queue. We can utilize node's EventEmitter to have a robust events system.
For commenting on resources you mean? What word filter would we implement?
@Arinerron Not just for commenting, but yeah. There's already a wordfilter in place - porter from the old os. Try swearing in your about me
We should use Scratch's swear remover. Theirs works much better, and then we can be sure Scratch approves if we use the same technology for filtering as them.
@nanalan Really? Scratch's filter is that bad at catching them? I remember a comment on @thisandagain's profile about which filter they used for commenting, and I'm fairly certain it wasn't how we are doing it :P
Didn't OpenSprites previously use a big list of swear words? I remember seeing a link somewhere in the old repo.
@Tymewalk Yes, and that's what we're using now. It's the same as llk/s2forums, but apparently that's not what they use in production...
Ideas:
Message schema
type: enum [comment, download, collection_add, forum_activity],
subtype: enum [resource, collection, profile, forum_section, forum_topic],
where: {
kind: what schema this links to,
item: ObjectId to wherever this is located
}
when: Date
(more info can be gained from the ObjectId link to generate the message)
Alert schema
from: String (moderator name)
message: String
when: Date
I'll turn the current User model into an OpenSprites model like I did with Resource and Collection and then we can add this :package:
Also, instead of spamming users messages for each individual action that occurs (like Scratch), we should collapse messages in the queue
Example:
- SampleText, Bob, and 10 others downloaded Archive the Cat
- Nanalan added 10 things to your collection ADD EVERYTHING COLLECTION!!!1
We should also have settings for what types of messages to display (filter by type and subtype fields we have in the schema)
A filter would be nice. Which 'phase' would be better for filtering things out, though? Backend or frontend? (out of curiousity)
Rule #1 of web programming is that you never trust the client.
If we let the client do filtering, haxx0rs would submit unfiltered content
@MegaApuTurkUltra I thought @Rumanti meant the client doing something like this?
const res = await ajax.get('/messages')
const filter = { type: 'comment' }
let msgs = res.filter(msg => msg.type === filter.type) // here!
// do something to parse the mesages into htmk
document.querySelector('#messages').innerHTML = msgs
If we let the client do filtering, haxx0rs would submit unfiltered content
...but they don't submit anything, right?
Oh, I was confused because we were talking about bad word filtering in this thread 😜
We should do it on the server to avoid sending unnecessary data to the client though
But if we can do it on the client, it'd basically be instant - and it can be in a single page rather than forcing the page to go to/ajax.get /messages?type=comment