nickwitha_k (he/him)

  • 5 Posts
  • 744 Comments
Joined 2 years ago
cake
Cake day: July 16th, 2023

help-circle





  • As someone else stated, they are indeed worse than people say. The has been massive consolidation in the industry, to the point where nearly every app is owned by the same company. And that company has been caught, multiple times, catfishing their own users with bots that then ghost them.

    The company is pure Chicago School economics; they don’t care about their users or product, just extracting money from people. Generally, this is men (though not always) as the culture cultivated in the apps is pretty shallow and messed up.

    Overall, it’s a much better time to engage in some sort of social hobby of the like. Success rate will likely be higher and the experience less depressing.






  • In that case, my suggestion would be to target implementing a REST API with OpenAPI (formerly Swagger). There are server code generators for both Rust and JS (multiple flavors, I think).

    Basically, the workflow is something like this:

    1. Create your API spec skeleton (YAML or JSON, pick your poison). This will have all of the required sections like info
    2. Pick your first endpoint and define it in the paths section. Probably start with during simple like a GET. This will mean that you mainly have to worry about defining your responses (at minimum HTTP2XX and HTTP4XX, preferably with a catchall error response for HTTP5XX responses) and their schemas.
    3. Run the code generator. This should generate files with stubbed-out definitions for interfaces (or the equivalent for your language of choice) for your response methods. Generally, you do NOT want to add any code to these files as they will be overwritten anytime you update your API spec.
    4. Implement the methods to handle the stubbed out interfaces. Ex. A hello-world interface would likely need to be implemented with a method or function that returns the string “hello world”.

    The reason that I recommend OpenAPI in writing REST APIs is that it helps to layout the API contracts before you even start coding. This helps with keeping typing consistent, give you a clear milestone for implement, and makes creating clients really easy.

    Extra benefit is that OpenAPI is (mostly) language agnostic, so, as long as you have a codegen or some good boilerplate, you can use it for any language, which can give you a safe place to start when learning a new language.







  • Midjourney makes money selling access to their model. Midjourney’s model, like those of OpenAI, has no value without the training data. In fact, the model is a derivative work of all of the works that it was trained on. The training data was obtained without license to resell or create derivative works.

    While I hate how much the Mouse has screwed with IP law and prevented productive reforms, I hope they refuse to settle and get a judgement that bankrupts Midjourney and establishes the precedent that AI companies have to follow the law and make licensing agreements with any creator’s works that will be used. Can’t exist as a company if that happens? Boo-fucking-hoo. It’s not society’s job to subsidize the wealthy’s desire to run a business model that depends on violating the law and causing financial harm to artists.