littlebigrefresh / refresh Goto Github PK

Idea stripped right from osu!

On the profile, there would be a list of levels where the player has achieved the spot with the most score on a level. A bit like this:

I was looking to play-test this and I was confused whilist patching, it said that I should not patch it with 10061 port then what URL do I patch this with?

From the command line or API, administrators should be able to perform a couple tasks.

• Banning a user
• Resetting passwords for users, then prompting them for a reset
• Marking a user as administrator

Did some discussion on Discord today starting here in #dev-main between @Slendy, @turecross321 and @Beyley. I'll summarize our conversation in this issue.

An initial plan was to implement a traditional IP authentication system, but this turned out to be a pretty bad idea. We then settled on having IP authentication fallback incase the primary authentication system, ticket verification, fails.

Hashing the IP address before storing it in the database was brought up, but was ultimately dismissed as it could cause confusion, and since there are many more hashes than IP addresses it could be easily reversible should a data leak occur.

I came up with some pseudocode describing a potential login flow:

if(canVerifySignature) return login(ticket.username);
else if(serverSettings.allowsIpAuthentication) {
  if(!accountSettings.allowsIpAuthentication) {
    warnUser("ticket verification failed, if this was you enable ip auth");
  }
  requestIpVerification(ticket.username, request.ip);
}
else {
  warnUser("ticket verification failed and server doesn't support ip auth");
}

return Unauthorized;

The idea is to support the edge case of a user not being on PSN/RPCN if it's needed, but recognize that IP verification a bit more insecure/privacy invasive. Because of this, will be off by default both server-side and in account settings, so server maintainers and users get to decide if they are comfortable with storing their IP address short-term/long-term.

• Depends on LittleBigRefresh/NPTicket#1

Should be mostly straight-forward, just hook up /lbp/searches to the existing category system

Pretty important i'd say

Can be mitigated by running as admin, but this should be fixed

Please watch the attached video:

Publishing only worked once, and that explains how I published the "Flung." level

It would be cool to rank people by the amount of hearts or plays their levels have gotten.

It could encourage making levels, or you know, it could backfire and cause H4H to be an annoyance again.

Talked to ture today, discussing various aspects of our APIs. The subject of sorting and listing came up, and I realized that Refresh isn't very great at returning this type of information. It's virtually impossible to have pagination with this system - the database does not return the total number of slots in most cases.

It also might be a good opportunity to have things be properly documented this time. Write some xmldoc, have some sort of script read it and push it out to a big markdown file.

One of my personal gripes is the PascalCase types - JSON REST APIs typically use camelCase. Also, it may be better to have dedicated Request/Response types for each endpoint when applicable. This is something SoundShapesServer has done and I'm starting to grow fond of it. I might also break out the types for GameEndpoints, as well.

The biggest challenge by far with implementing all of this is going to be keeping support for v2. I don't know of any applications built on v2, so it might just be safe to scrap it and not have to deal with the baggage.

A group that a user can form, and other users can join it. (if the group is open as opposed to invite-only)

We can probably represent groups with a dollar sign or some other symbols?
$Clan for example, no spaces should be allowed.

• If #44 is implemented, we could also have a group leaderboard instead of just an individual user leaderboard

• Users can transfer their levels to a clan, and they will share a single earth - and can be searched for in-game like normal levels

• Photos of clan members can also be shown

• List of events in Realm
• Photos uploaded, news, new scores, etc.
• Should be exposed to API

• Option to cache on disk/always convert
• Pull from API (e.g. /api/v2/asset/{hash}/image returns a image/png)

Instance owners should be able to lock down a server to only allow administrators to log in/access the website. Helpful for those who are under attack/assessing damage, or simply want to do manual database work without noise.

Similar to Discord. Will be pretty helpful for larger instances

• User can have multiple roles (?)
• Roles detail what actions can be taken by the user (can this user post comments, can this user ban other users, etc.)
• Roles may optionally display a badge on the users profile
• Has default roles (User, Admin) but still configurable by administrator

To implement:

• Administrator role
• User role (default)
• Restricted role
• Banned role

Submitted scores should be exposed to API, but not score submission itself for obvious reasons

This leads to PS3 players trying to join RPCS3, and RPCS3 players trying to join PS3

• Track who uploaded an asset, and when
• Track type of asset (#22)
• Track dependencies of asset
• Add migration to backfill data into database from DataStore
• Track size of asset (#66)

We can use this information to be able to purge unused assets/delete assets by a certain user

For example, things like hearting, rating, reviewing, queueing

Including but not limited to:

• lbpcool/lbp2cool (lbp1, lbp 2 and lbp vita cool levels)
• thumbs (highest rated)
• mostHearted
• mmpicks (team picks, depends on #68)
• mostUniquePlays
• busiest

Format for LBP1 was recently uncovered:

<news>
    <subcategory>
        <title></title>
        <item>
            <subject></subject>
            <timestamp></timestamp>
            <content></content>
        </item>
        </subcategory>
</news>

News in LBP2 is handled in recent activity
#16

Thanks to @W0lf4llo for bringing this to my attention.

After someone opens the game and uses the /match endpoint, their room will show indefinitely until the server is restarted.

Should be a worker that just scans for recent Events about every 5 minutes or so

Trying to join on a specific level attempts to join the wrong person, instead of the player actually on the level

We can use the new Worker system to periodically check for new users, and then look for unattributed users in photo subjects.

So userA uploads a photo with userB, without userB being registered. userB gets tracked in the uploaded photo with a username (missing their GameUser association), and then userB registers. At this point, the uploaded photo still hasn't tracked their signup accordingly, so our worker runs and updates the photo to add the GameUser to the photo subject.

Will be extremely helpful for archival efforts

Users are opted in by default, but if they choose they can disable downloads for their levels

can i be in it

• Bans should expire
• Include reasons for ban

It's an absolute mess, and it depends on a lot of hacks/assumptions to work correctly.

Instance owners should be able to create 'announcements' that show up in-game and on the website as a banner, similar to a notification but not quite.

For the API, they should be included in the /api/v3/instance endpoint.

Related: #17

A mod filter should be implemented with 3 modes

1. strict: only game files usually sent by users (.tex, .jpg, .plan, text strings, ect) can be uploaded
2. lenient: game file types, such as .mol, .anim, .gmat, .mat and .bev are allowed on the server, but .ff files are still unallowed
3. none: lets users upload anything they want

• Enforce tighter rate limits on these endpoints
• Don't allow user to be registered immediately, wait for game handshake to activate account
  - [ ] Trial period for new users? Don't allow commenting/relations through API for a little while, but may be too strong of a measure Unnecessary for now, we'll gague later
• Simple password requirements (8 characters, don't want to be too strict on this)
• Email verification. Must-have.
• Users should not be able to steal accounts from other platforms. A PSN account should not be able to be logged into from RPCS3 if not explicitly allowed by that user.

• Notifications store title, text, FontAwesome icon, date, and color (as hex string)
• Stored per-user, can be retrieved through API
• Can clear notifications individually and all at once (history does not get preserved!)
• Notifications can also show at announce screen, sorted by most recent to oldest

• Track Platform and GameVersion (this should also track if the token is an API token aswell) (#37)
• Login date (2866173)
• Add support for passing in a token in Bunkum (PlanetBunkum/Bunkum@d7a4617)
• Maybe point to recent events? Could be used to display more information to user through API if a level upload was rejected for example. Would also be good for audit log

Right now, we just do string comparisons on args[0] on startup to check for commands. This isn't ideal, since it doesn't provide a help menu or any real documentation.

I've had success with CommandLineParser in other projects, so this could be a good start.

Technically we should just skip straight to tracking the actual revision number in the level file but for now I think it's acceptable to just use the token's version number

To properly comply with GDPR

• Deletion
• Export