Paper-centric rather than user-centric accounts

[grasshoppermouse]

This is a great project!

Design Proposal

Yesterday, I posted a thread on Bluesky arguing that giving papers their own Bluesky accounts might be useful:

Bluesky thread

I've just starting looking at chive, and from the perspective of the chive appview, it might not make much difference (true?), but papers having their own Bluesky accounts would mean they would be first class citizens in the broader Bluesky ecosystem. Posts from paper accounts about, e.g., new versions, follow-up studies, news coverage, retractions, etc., would show up in followers' Bluesky feeds, enabling richer engagement with research. Papers, which usually have many authors, would also not be so closely linked with a single author. This would complement the more traditional structure that chive seems to embody (e.g., peer reviews).

Thoughts?

[aaronstevenwhite]

I really like this idea, @grasshoppermouse! Do you have thoughts on how to programmatically set up paper PDSes?

Chive currently assumes that users already control a PDS–wherever (and by whoever) that's hosted–and that they give Chive permission to write to it. But to give each paper its own PDS, those PDSes would need to be programmatically created on submission.

One thing I'd like to avoid is hosting PDSes or paying a hosting service, which will become cost-prohibitive quickly without some sort of grant or sponsorship. That would seem to leave either:

1. programmatically creating PDSes on a "free" hosting service–e.g. by programmatically creating a bluesky account for every paper (which seems likely to quickly hit rate limiting); or
2. assuming that users will independently:
   1. create a paper PDS (either by setting up their own or by creating a bluesky account for it);
   2. link it on submission, at which point Chive would
      1. write the paper's metadata and relevant blobs to the paper PDS, then
      2. write pointers to the user DID (and presumably pointers to the paper's DID from the user's PDS, where coauthors would add pointers to the paper's DID using the claiming service).

I worry that (2) is somewhat cumbersome and likely to lead to attrition. Thoughts on implementation?

More generally, do you have thoughts on desiderata for what kinds of objects should be a first class citizen (and thereby get their own PDSes)? For instance, review threads are also structured objects that could have their own PDS. An argument for that is conceptual that they are a scholarly product much like a paper that themselves can be discussed.¹ An argument against is more practical in that it potentially results in too much indirection, which would result in higher latency and more opportunities for reference rot.

---

¹ And actually Chive additionally has notions of structure for reviews that go beyond simple threading that come from the information extraction literature, which is where I'm coming from, including span-level typing against the knowledge graph/ontology.

[grasshoppermouse]

Long term: I envision universities, granting agencies, and other research institutions hosting PDSs, in which case (1) would be viable and the best way to go.

Short term: I was envisioning (2), but I agree with you it's a bit cumbersome and likely to lead to attrition. So, I'd go with (1), programmatically creating accounts on bluesky to see if this idea takes off. If it does, try to wrestle up funding or a sponsor before you hit rate limits. The best would be to get an organization like Zenodo.org that already archives scholarship and research data to run a PDS hosting service.

As for first class citizens, my first reaction is that review threads should not be -- they should be closely linked to the paper. But I haven't given this much thought. I have to head out to appointment, so I'll leave it there for now.

[aaronstevenwhite]

Thinking more about (1), I think the only feasible way to implement that approach is as a version of (2): com.atproto.server.createAccount is called client-side on paper submission, the resulting DID is passed to Chive for indexing, and Chive helps the user write the paper record. Server-side calls would be immediately rate-limited and don't make sense philosophically anyway.

What I'm thinking I'll do is to set things up such that papers can either be viewed as identities or records from the perspective of authors. Then, if an author would like to go the manual route (e.g. yourself @grasshoppermouse), they just provide the paper DID on submission and writes are made to the corresponding PDS. Later, I may try to implement automatic account creating using client-side calls to com.atproto.server.createAccount; but for the sake of the alpha (and probably beta), I'll likely leave the manual option as the only one that supports paper's have their own identities (rather than being viewed as records).

[aaronstevenwhite]

The option to associate a paper with it's own DID is now implemented in lexicons/pub/chive/eprint/submission.json#paperDid.

[grasshoppermouse]

Great, thanks!

[aaronstevenwhite]

@grasshoppermouse while this is in the data model, I'm still working out how to do auth in the paper submission form. Basically, how this will work is that users will be given an option at the start of the submission wizard to provide a paper handle that points to a PDS they have set up independently (for now; still thinking about automatic PDS provisioning). The form will then write to that PDS on submission. The tricky part is making sure auth is handled correctly for both the user and the paper, since we don't want to kick the user out during paper submission.

I mention this because I noticed you applied for the alpha with what looks to be a paper handle. (Possibly this was due to the early DID resolution bug with non-bluesky accounts that I fixed Thursday.) If you did apply with a paper account, can you instead apply with your user account? Once I finish a few bug fixes, I will turn back to figuring out the auth for paper PDSes and you will be able to use the paper account on submission.

[grasshoppermouse]

Just applied with my main account.

Regarding automatic PDS provisioning, I'm curious what your thoughts are. My understanding of the atproto architecture is still pretty rudimentary. Just for ducks, though, I set up a PDS on a cloudflare worker (free tier), using cirrus:

https://bsky.app/profile/pds.edhagen.net

But it seems the ideal solution would be to partner with eprint services like osf.io, Zenodo.org, arxiv.org, etc., and have them implement a PDS interface on top of their existing archiving infrastructure.

BTW, thanks for taking this idea seriously.

[grasshoppermouse]

Bluesky developer blog post outlining ideas for group accounts, which could be useful for paper accounts: https://bnewbold.leaflet.pub/3me3ea64bhk26