polyphony-chat / chorus Goto Github PK
View Code? Open in Web Editor NEWA rust library for interacting with multiple Spacebar-compatible Instances at once.
Home Page: https://crates.io/crates/chorus
License: Mozilla Public License 2.0
A rust library for interacting with multiple Spacebar-compatible Instances at once.
Home Page: https://crates.io/crates/chorus
License: Mozilla Public License 2.0
Cover all API routes which concern themselves with deleting messages.
Cover joining and leaving message threads and actions concerning Forum channels (pinning, unpinning, tag creation, assigning, etc.)
Currently a new https client is created for every request, however the Client
docs state:
/// The `Client` holds a connection pool internally, so it is advised that
/// you create one and **reuse** it.
///
/// You do **not** have to wrap the `Client` in an [`Rc`] or [`Arc`] to **reuse** it,
/// because it already uses an [`Arc`] internally.
Cover Group DM creation, deletion and member management.
Implement message sending via the API
The following checklist should be completed for a release build of Chorus. The list is sourced from here: https://rust-lang.github.io/api-guidelines/checklist.html
These so called API Guidelines should not be forced upon the project, but be just that: a set of guidelines to look up to and apply whereever it makes sense.
as_
, to_
, into_
conventions (C-CONV)iter
, iter_mut
, into_iter
(C-ITER)Copy
, Clone
, Eq
, PartialEq
, Ord
, PartialOrd
, Hash
, Debug
,Display
, Default
From
, AsRef
, AsMut
(C-CONV-TRAITS)FromIterator
and Extend
(C-COLLECT)Serialize
, Deserialize
(C-SERDE)Send
and Sync
where possible (C-SEND-SYNC)Hex
, Octal
, Binary
formatting (C-NUM-FMT)R: Read
and W: Write
by value (C-RW-VALUE)?
, not try!
, not unwrap
(C-QUESTION-MARK)Deref
and DerefMut
(C-DEREF)bool
or Option
(C-CUSTOM-TYPE)bitflags
, not enums (C-BITFLAG)Debug
(C-DEBUG)Debug
representation is never empty (C-DEBUG-NONEMPTY)The UserMeta
(or User
) struct should have a method, which gets all guild objects which the user is a member of.
All types have been moved to a separate repository for re-usability. Chorus will be refactored to use these types instead of the current, duplicate types.
One should be able to modify, create and delete Roles and their permissions. This extends to modifying role and user permissions on channels and channel categories.
I just realized, that the Rate limiter counts your rate limits per-instance, and not per-user.
Of course, some limits like Global and IP are shared, but all the other limits should be per-user instead. This shouldn't be too hard, mostly some restructuring.
Implement the route described here: https://discord-userdoccers.vercel.app/resources/channel#get-private-channels
the Guild
struct should have a method which can get a guild object by the guild id.
There needs to be a working implementation of a gateway, which connects to the Gateway of an instance and can send and receive messages. It would be great if the Gateway would emit 'events' on things like message received, message edited message deleted etc. These events could then, for example, be used by the client to update its UI when the event happens.
Add, delete, modify and get server emojis.
Add support for sending and receiving live streams of WebRTC Video and Audio.
Rust generally uses Option::Some
/Result::Ok
to indicate success and Option::None
/Result::Err
to indicate failure. Both implement the Try
trait, allowing easier error management with ?
.
For functions that don't return a value on success Chorus does the opposite and returns Some
on failure and None
on success. This can be better represented via Result<(), ChorusLibError>
. It's also convention to define a helpful type alias: type Result<T> = std::result::Result<T, ChorusLibError>;
.
A feature should be added that allows RateLimits to be written to disk as .json
, .yml
or another format such as .kdl
. This would allow RateLimit information to persist, which would make it harder to run into rate limits by accident.
Add all reactions routes.
It should be possible to modify all aspects of a user profile using this library. This includes, but is not limited to:
Currently, you can "only" login to the API using the conventional way, which is using login and password. It'd be good if one could login using their token as well.
The current unit and integration tests are really nice, but they should be restructured in my opinion. A lot of integration tests overlap, which leads to a lot of code duplication in the testing area. This should be avoided, which is why I think a restructuring is needed.
Helix uses tokio features ["rt", "macros", "rt-multi-thread", "full"]
. full
enables all features – as chorus is a library, it should only enable those it needs.
Ensure support for Threads, Forums (and their sub-channels), announcement channels, and anything else that gets added to this list in the mean time.
Tasks:
The foundation for Gateways has been made! The library now allows you to write code which immediately runs, when a specific event is received via the gateway.
However: Actually communicating with the gateway and receiving those events is where I have failed until now. I just couldn't get it to work the way I would have liked to, and I require help on this one.
From my POV, an ideal implementation would have each Gateway/Websocket running in a seperate thread. Each gateway thread updates the GatewayEvent
s (defined in src/gateway.rs), which would trigger the observers.
The build is currently failing. This is, because the server likely does not have the correct/up-to-date schemas. Should be fixed.
Message::send
(as well as UserMeta::send_message
) take a files
parameter for attachments, however the MessageSendSchema
already has an attachments
field. Currently both must agree with each other. Removing the files
argument would fix this.
Additionally, the send
takes the message by mutable reference (to set attachment placeholder ids), but doesn't document what it mutates. It should either take it directly, document it, or take it by shared reference and not actually change the placeholder ids (which have to be unique, but don't have to be continuous).
The two integration tests currently fail. This needs to be fixed ASAP
Trying to connect an Instance to discord.com's api yields the following error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("invalid type: string \"404: Not Found\", expected struct Message", line: 1, column: 28)', .../src/api/policies/instance/limits.rs:328:52
This happens because discord.com doesn't implement /policies/instance/limits
(since that's a spacebar only endpoint :P)
It returns {"message": "404: Not Found", "code": 0}
when chorus tries to deserialize the response into the Limits Config struct
pub struct Config {
pub user: User,
pub guild: Guild,
pub message: Message,
pub channel: Channel,
pub rate: Rate,
pub absoluteRate: AbsoluteRate,
}
invalid type: string \"404: Not Found\", expected struct Message
comes from the message
field being the same in the real response and the 404 response
Check if the GET limits requests returns a 404, if it does, fallback to a default (discord.com's default ratelimits)
Similar to libraries like discord.js, Chorus should create structs, which update themselves.
If we, for example, get a User object with let user = User::get(<info>);
, and this user updates, for example, their Display name, with the current implementation, the user we just defined would already have out-of-date information.
We already receive events such as this Display name update over the Gateway, as soon as they happen. There should be a way to automatically incorporate this info we already receive into the actual object we create, so that we always have up-to-date information, without needing to re-query the API (which is quite expensive).
There are a lot of print statements in src/gateway.rs
that shouldn't be there. If logging is desired, use log to give control to users.
It should be possible to modify all aspects of a user profile using this library. This includes, but is not limited to:
The current implementation of the Gateway always requests all intents for a Gateway connection. This should be configurable.
#42 does not implement every user setting there is. This should be done here.
Currently only a few of the events the server can dispatch are implemented, further ones need to be added to Events and transcribed from the docs into rust types. (A lot of these require more complex types like Guild, Sticker etc)
Making an issue to track the progress of implementing every gateway event
Also, I am working on this already :)
One should be able to create and delete guilds using this library
It should check both username & password length
→ shouldn't return a result
Schemas.rs is getting pretty big. It should be split up into schemas.rs (which contains actual schemas like the LoginSchema or RegisterSchema) and types.rs, which will contain things like Message, Guild, Channel, etc.
There are a lot of cases where chorus panics instead of handling errors, chief among them in deserialize_response
when a request fails. This should not happen, encountering errors is expected.
Additionally, ReceivedErrorCodeError
contains the http status code of the failed request, but discards the response body (at least the spacebar server returns useful information about why the request failed), making debugging harder.
Less important: The error handling code can be more succinctly expressed using idioms such as the try operator (?
) or .map_err
and friends. Also, since this crate is called chorus, not choruslib, the main error type should be called ChorusError
, not ChorusLibError
; and because it already contains "error", its variants don't need "error" as a suffix.
While types and names convey the most important information, often doc comments are helpful or necessary. The current ones still have some issues though:
///
, but some use /**
Channel::modify
/// Edits the permission overwrites for a channel.
///
/// # Arguments
///
/// * `user` - A mutable reference to a [`UserMeta`] instance.
/// * `channel_id` - A string slice representing the ID of the channel.
/// * `overwrite` - A [`PermissionOverwrite`] instance representing the new permission overwrites.
///
/// # Returns
///
/// This function returns a result that is either [`Ok(())`] if the request is successful, or an [`Err(ChorusLibError)`].
pub async fn edit_permissions(
user: &mut UserMeta,
channel_id: Snowflake,
overwrite: PermissionOverwrite,
) -> ChorusResult<()> {…
Reactions::get() returns a generic success/failure, when it should return a list of users instead.
the rate limiter should return more custom errors instead of just generic ones. I have already started with this in #44, but this still needs some work.
There should be a test for login in. Related: There is an existing auth test for account registration, but the common test bundle setup functionality performs a registration beforehand anyways, so that test can probably be removed.
Provide Register and Login functionality using the API Wrapper.
Fetching the general instance info for discord.com fails, because discord.com doesn't implement the endpoint /policies/instance
and just returns a 404.
This makes new Instances unable to connect to discord.com, since Instance::new returns ChorusError::CantGetInformation
if fetching the instance info fails.
2-Factor-Authentication functionality should be checked for functionality.
Permission overrides for channels and categories, which can be set for roles and single users alike.
Cover all friend- and blocking-related routes.
Inside UserMeta, the instance is stored in an Rc. However, calling login_account
/register_account
on an Instance
creates a new copy of the instance. Is this intentional?
If not, this could be fixed by changing the functions to take an Rc<Instance>
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.