citrons

æ.

that's against the laws of physics.

well, yes, because non-fresh orange juice isn't stale, due to the impossibility of staling.

my juice is stale.

impossible. anyway, you should know what to do, in this case.

the juice

you are immune to propaganda, so you can believe me when I say so.

yes.

the website should probably exist.

you could ask them.

well, I speak only for myself in saying this, but perhaps the speed at which applications are processed is reflective of a nonfunctional sense of time.

171 days ago??

so sad.

good.

i thought ./well-known was an april fool's joke

why in the world would you think that?

why would someone have both /.well-known/citrons/auth and /citrons/auth?

I'm not saying they would. just read RFC 8615. it explains /.well-known.

why /.well-known/citrons/auth? why not just /citrons/auth?

what if you wish to have a page at /citrons/auth? /.well-known is a standard path for these things.

this is seriously cool!!

thanks!

I have many potential/work-in-progress projects which require account systems. I figured heav, apparently, figured that optimally, I should implement this once and then never again. this is ultimately better for the user, also, as they must keep track of fewer accounts.

as such, auth.citrons.xyz exists. it is usable by anyone; though, I disclaim responsibility if it explodes.

the API documentation is todo, but the gist of it is this:

a service is identified with a domain. to discover a service, e.g. example.com, the authentication service queries https://example.com/.well-known/citrons/auth. this is required to be a JSON file containing the following properties:

• name - the name of the service
• endpoint - a URL in your application a user id and token can be POSTed to.

when you wish to log in a user, link them to https://auth.citrons.xyz/login?service=<domain>. the user confirms by submitting a form to your endpoint. the form contains the user's ID in uid and token in token.

you can then query the status of a token by posting it to https://auth.citrons.xyz/api/user/<user_id>/auth/<service_domain>.

$ curl --request POST \
    --data 'token=XXXX' \
     https://auth.citrons.xyz/api/user/50fc23f03043d139/auth/example.com
{"valid":true,"user":{"username":"citrons","ttl":800,"uid":"50fc23f03043d139"},"ttl":800}

$ curl --request POST \
    --data 'token=invalid'\
    https://auth.citrons.xyz/api/user/50fc23f03043d139/auth/example.com
{"valid":false,"ttl":9999999}

ultimately, it is now possible to log in. by the way, I have designed the site around the new style I am working on for my site redesign, my new webæsthetic.

enjoy. tell me if you find some horrible bug.

right. the problem with them is only that they're predominantly unfinished, which is just... what happens with video games. it's just hard in general to make video games.

making video games? yeah.

pertaining to the module system, my ultimate goal would be to create a package manager and repository, but this would depend on package ecosystem/playerbase to exist first.

I feel like you're referring back to a previous conversation, but i can't remember which; could you please remind me?

consider the case of modding APIs, or breaking compatibility. whether or not a modding API is a good fit for this game specifically, I find that you have taken hardline stances on software that I disagree with in the past.

Perhaps i stated my goal wrong. Maybe a better way to phrase it would be that i want to create a game that's better at being Minecraft than Minecraft is. Or perhaps i could say that there's a certain happy feeling i used to have when playing Minecraft when i was youngerand less disillusioned with the world, and i want to be able to recreate that feeling.

I see now. that could be interesting.

If the consensus of the populace is that doing something would be the most fun, that's what should be done; if everybody's saying that something isn't fun, it should be removed; if experiments reveal that people find something more fun than expected, that should influence the decisions.

that certainly makes sense.

(I'm curious about what you specifically mean by the design goals you listed, though.)

well, I plan extensibility in the form of a module system, in which the game is constructed from modules which interact with each other by exposing public APIs and which can be used in different combinations at whim (as long as they don't conflict).

in terms of actual game mechanics, I want to design the game such that blocks in the world have interesting interactions, and hopefully emergent mechanics. my ideas hinge heavily on my reinterpretation of the voxel engine, wherein multiple blocks at once can fit within a space. this is implemented partially and inelegantly in minecraft in the case of waterlogging and slabs, but I wish to implement this generally.

I think that the main mechanics that the player will interact with to make mechanisms and generally get things done are heat and water. water, unlike in minecraft, will actually be finite and flow into different blocks akin to minecraft. heat will likely be producible by combusting fuel and by other means, and I think it will be the means to power mechanisms like pistons.

pistons will be akin to those in minecraft, but they will be much more powerful. utilizing the ability to contain multiple blocks in a space, one will be able to apply a gluelike block to the sides of blocks, which will cause them to be moved as one when pushed by a piston.

for implementing logic, my current idea is to have a funguslike substance whose stem conducts heat very well and whose head implements logic gates. the fungus would be found on the roof of a certain type of cave underground, and may be cultivated by the player once found.

pertaining to world generation, I want to feature detailed and fantastical environments. the world generation will take advantage of the "infinite" nature of the world, both horizontally and vertically. as one moves further from the center of the world, the environments become more fantastical, and as one ventures deeper into the ground, one is able to stumble upon the otherworldly. I'm not sure what should be in the sky, but perhaps there would be floating islands or celestial objects.

the inhabitants of the world, i.e. mobs, will generate with the world and not spawn spontaneously (at least, predominantly), unlike minecraft. though some might be dangerous, none of the mobs will exist simply for the purpose attacking the player (except maybe for one exception that I have in mind). I wish to have them exist in a sort of simplistic ecosystem, where the actions of the player could affect their populations.

in any case, your elaboration of your goals has given me a better idea of the project, and I think it could be cool.

I don't really agree with you about what many of the problems with minecraft are, how software should even be structured in general, or why people play video games at all. so, I don't think that we could agree on a direction or a design for such a thing, if I were to help.

I also aim to create a minecraftlike, and my design goals are for it to be very extensible and implement the mechanics I would like to see in a minecraftlike, as well as world generation that begets interesting and strange environments. I haven't, however, made very much progress at all on my own project, so regardless of the direction of your project, I probably wouldn't be of much help anyway.

my project doesn't aim to replace minecraft. I don't really think that goal makes sense, and I don't think such a goal would result in an actually good game. if you make a new game, it's a new game. a game which is different does not replace minecraft by definition. this is why people play different versions of minecraft. sometimes I want to play minecraft 1.8. sometimes I want to play the latest version of minecraft, or with mods, etc. sometimes I want to play minetest. you don't seem to comprehend that people want to play different kinds of games at different times, as when I pointed this out to you before, you called it "addiction to novelty".

it would be a different story if the goal was to attempt to reimplement minecraft as an open source piece of software, which would be venerable. there is already a project to do this, called mineclone, which is made in minetest. however, there are many deficiencies yet that prevent it from acting as a complete replacement for minecraft.

well, I'm not really an expert in this. I think it just comes down to being administrated well.

official documentation takes effort to produce and is thus often not provided. wikis are an effective way to collaboratively produce content and can be quite high quality if done right.

clearly, this post doesn't exist.

oh no.

oh, true.

actually, they did exercise thread 367. also of note is that I vetted this website 127 days ago.