<isd>
capnproto.org may be important background info.
<isd>
We use this for most of the internal APIs on the server side, though in some cases we have some shims for compatibility.
<prologic>
Any examples of doing the web publishing stuff from Go using this library?
<ocdtrekkie>
I think we could probably get at least a working MVP of things using the getPublicId thing and using Ian's proxy as a separate executable, though doing stuff all clean with Go would probably be a nice goal.
<isd>
I'm not sure there are, actually :/
<isd>
ocdtrekkie: given that yarn.social is already in Go, I don't think there's much point in wrapping it in an executable. Though we should probably ship something like that with sandstorm (I think there's already an issue for that somewhere).
<isd>
Let me see if I can dig up some useful tidbits.
<ocdtrekkie>
There is an issue I read yesterday which included Kenton's notes about what he'd like to eventually do.
<prologic>
I can probably write a new session manager for Sandstorm+Yarn.social and re-generate feeds in /var/feeds/ to be served up by the web publishing, that's pretty straight forward
<prologic>
But I'm gonna need help with the other bits maybe? (Outbound connections, pulling other feeds in)
<prologic>
And this getPublidId thing
<ocdtrekkie>
Yeah, I can probably help you put together the existing example of that.
<ocdtrekkie>
Basically it is a little executable which returns the public URL of the web published content.
<prologic>
ocdtrekkie if your around I have some extra design-type questions
<prologic>
X-Sandstorm-User-Id: If the user is logged in, this is set to the user's current user ID, which is the first 128 bits of a SHA-256. For example: 0ba26e59c64ec75dedbc11679f267a40. This header is not sent at all for anonymous users.
<prologic>
Ugly as sin but ok :D
<prologic>
And
<prologic>
X-Sandstorm-Preferred-Handle: The user's preferred "handle". A handle is like a Unix username. It contains only lower-case ASCII letters, digits, and underscores, and it never starts with a digit. The user can set their preferred handle in their account settings. This handle is NOT UNIQUE; it is only a hint from the user. Apps that use handles must decide for themselves whether they need unique handles and, if so, implement some mechanism to deal
<prologic>
with duplicates (such as prompting the user to choose a different one, or just appending some digits). Apps should strongly consider using display names (X-Sandstorm-Username) instead of handles. WARNING: A user can change their preferred handle at any time. Two users can have the same preferred handle. The preferred handle is just another form of display name. Do not use preferred handles as primary keys or for security; use X-Sandstorm-User-Id
<prologic>
instead.
<prologic>
So since Yarn.social really uses "Usernames"
<prologic>
I'm tempted to just use the Preferred Handle
<prologic>
But this is optional on Sandstorm's side right?
<isd>
I'm pretty sure it will always be there if the user is logged in.
<ocdtrekkie>
Preferred Handles should exist and should be what you use for a username, provided it doesn't already exist in the pod, yeah.
<isd>
Driving usernames from it makes sense, but you need to make sure (1) you have logic to deal with collisions, and (2) you don't use the field for authentication; most likely you'll have to maintain a mapping from X-Sandstorm-User-Id to usernames
<prologic>
Yeah that's fine
<prologic>
My question most mostly whether I could use it at all
<prologic>
Or whether by default the field is blank in Sandstorm :D
<prologic>
But yeah I will map User Ids from Sandstorm to internal User objects with a mapping of id -> username (preferred handle)
<prologic>
Just gotta figure how to do this without breaking the world :D