Just to add another dimension to the use cases. In addition to domain-specific reasons for accurate dates, there are some provenance modelling reasons too. For example, adding a statement reference (or qualifier) that describes when a statement was observed or known to be true. For this it would be desirable to have full ISO8601 (i.e seconds, but why not milliseconds?)

Thanks for all your help @Dzahn @jijiki @RyanSteinberg . I can now log in, all working as expected.

This was created, in error, using the standard arguments for ssh-keygen, i.e. RSA 2048, SHA256. My mistake.
Per https://phabricator.wikimedia.org/T209298#4799902 , my new public key is:

@jijiki Sorry this is getting drawn out!

It appears I supplied a key in the wrong format. I believe this is preventing me from signing in. Would you please replace with for my afandian2 account:

@jcrespo The account name is "Joe Wass".

Sorry for the confusion, I'm struggling to understand how many different types of accounts I need and how they link up. The Phabricator account I am logging in with is the only one I have access to.

public key:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsJPyatQmAgubnM6ChTohZdEYTOfVJjzpsOtiVrBcwTOVBwEl3qcORlMEF0MMk+BdMfiMd12jmfxGWuOhzJAZ8iPDE9Bk9z0/ttb6NJj09CfO5YlfOsgi8gAXthZ7gAX7EulUVW1jKHksbG3tS7zIxmx5+GzHWJ6SGapKsUrf2LC0RwQkiNyha2535vZlvmbMRhaICeN9F/2GCSoEbgdvf2+4Ln3hO/me5EcKvxDfXCcCYklHxNS9ikfK84RpXd8EfIv2tmf1LYWw38DUVv6io3ehuar7c/twBTmodiKqkkywLHNY0u6KFAnKEsBuQ989CiepxIJjb+NYd+KuZvMBh jwass@herring.local

@Ottomata I'm happy enough using the current Socket.io 0.9 client for Java (even if it is deprecated!). I don't have any complaints about the current situation beyond the protocol being a little long in the tooth. My preference would be something with supported libraries available so I don't have to worry too much about maintenance. If you just upgraded to a supported version of Socket.io I'd be happy.

I see a lot of browser-based discussion here. I'd just like to contribute my voice as an existing consumer of the existing RC Stream and hopeful consumer of whatever follows.

Cool, thanks for considering my suggestion. It was based on the incorrect assumption that you would be looking to replace Socket.IO.

Great to see thinking on this moving forward. Can I put in a vote for the most portable possible technology for connecting? For starters, there are current clients to RC_Stream in Python, JavaScript, Java, who knows what else. It would be a shame to increase the barrier to entry for migrating existing clients.

Joe from Crossref chiming in here.

Thanks @Krinkle. It was worth asking... Looking forward to seeing a 1.0 version. Looks like library support in a few languages is good for 1.0.

This looks like a good opportunity to include diff information. A number of bots are watching the RCStream and immediately fetching relevant diff. This is expensive for everyone, and having a new RCStream include this feature as an option would be great. See T100082

Yes. This is what Content Negotiation is for. The RAs (Registration Agencies) work together to expose this API via DOI. We also have various data formats that we all support. Information here: http://www.crosscite.org/cn/ . Long story short:

First, you can check for the existence of a DOI just by resolving the URL and seeing what response you get back. That's quicker than the API, and will serve to do a first pass of finding valid DOIs.

Cocytus was the reason we created this ticket in the first place, @notconfusing! Hopefully it will replace most of the code.

Sorry I'm not sure if we're talking at cross-purposes. I'm talking about the original purpose of this ticket (I did't mention RESTBase!).

I'd just like to add a use-case here. The reason we started this ticket is because CrossRef is interested in a live stream of citations of DOIs (we are the registration agency for most DOIs) as they are cited (and/or uncited). We are listening on RCStream and then fetching every diff to look for a DOI. The reason we wanted to move beyond this is because requesting a diff for every event is taxing on the server, high-bandwidth, requires lots of HTTP connections and probably wouldn't be practical to run this service on a remote server (it's currently on wfmlabs tools).

Hi guys, any movement on this?

jcreus already left and I don't need one. Please do not book 17:30! Or if you give me the number, I can call and cancel.

I think I will go to Lyon and take a taxi from there. Assuming you don't want to share a taxi from your other comments, @MarkAHershberger. Sorry for the problem @AlexCela.

@MarkAHershberger I made a typo, I am leaving tomorrow.

@jcreus Sounds good to me. I don't know how long it takes to get there. @MarkAHershberger

My flight is at 19:15 on 26th May, so maybe we can share a taxi jcreus, MarkAHershberger?

Thanks! If there's anything I can do let me know (I'm a programmer at CrossRef, most DOIs are registered by us).

After a quick chat with Jdforrester, I think this is currently preventing DOIs from being cited with the visual editor.