Post 9pgkrjmLbxKFU6ji9g by rysiek@mastodon.social
(DIR) More posts by rysiek@mastodon.social
(DIR) Post #9nelZtYRflKwzqRxqq by rysiek@mastodon.social
2019-10-06T18:03:01Z
1 likes, 1 repeats
Okay, hypothetically, if somebody was looking for a name for a Free Software project that focuses on Web censorship circumvention, using multiple configurable non-standard in-browser delivery mechanisms, what would a good name be?Asking for a friend.
(DIR) Post #9nelZtpodBEPriZpvU by kaniini@pleroma.site
2019-10-06T18:06:58.586143Z
0 likes, 0 repeats
@rysiek Streisand
(DIR) Post #9nemAJX6YxvdzZBmFc by hcs@pleroma.site
2019-10-06T18:13:35.782486Z
0 likes, 0 repeats
@rysiek What groups of users do you have in mind for this?Does the name need to state the main function in an obvious manner or is there room to have something more esoteric end and requires further explanation?
(DIR) Post #9nqmdKRVZmhPhEPwZc by rysiek@mastodon.social
2019-10-12T13:04:46Z
0 likes, 4 repeats
Ok, so we now have a shortlist of contenders for the new name of our little browser-based censorship circumvention project.Let's vote!The vote will not be necessarily binding, but I want to see if my feel about these names is correct.Thank you all for helping out and suggesting the names! Special shout-outs to @pelican3301 , @Shufei , @mjjzf and others who suggested some names.
(DIR) Post #9nqmdLLAErDcTqSOK8 by fitheach@mstdn.io
2019-10-12T13:15:13Z
0 likes, 0 repeats
@rysiek > The vote will not be necessarily bindingSee Boaty McBoatface for details...@pelican3301 @Shufei @mjjzf
(DIR) Post #9nquDuO66tq7HXDBtw by dredmorbius@mastodon.cloud
2019-10-12T14:40:24Z
0 likes, 0 repeats
@rysiek HemlockWycliffeSamizdatSubvertVoxPopBarlowRosnecGadflyOdysseusHorseZengerSunlightLux
(DIR) Post #9nquiINtSJ7GOTbd9E by rysiek@mastodon.social
2019-10-12T14:45:53Z
0 likes, 0 repeats
@dredmorbius *now* you throw these at me! ;)Samizdat is definitely a great name, damn! I wish I had thought of it myself! Will consider it (but won't republish the poll now).Thanks!
(DIR) Post #9nqzHFth5tIUdGPEnI by dredmorbius@mastodon.cloud
2019-10-12T15:37:03Z
0 likes, 0 repeats
@rysiek Sorry! I missed the earlier posts.
(DIR) Post #9nr0eHXfFGCoLce5OS by rysiek@mastodon.social
2019-10-12T15:52:24Z
0 likes, 0 repeats
@dredmorbius yeah, you should be sorry! ;)
(DIR) Post #9ntopIpndRAFdhrpke by rysiek@mastodon.social
2019-10-13T23:40:06Z
0 likes, 3 repeats
Well that went fast! Rename complete, code a bit cleaned, stuff tested.I give you SaΠΌiΠ·daΡ:https://git.occrp.org/libre/samizdatExample deployment:https://cdn.test.occrp.org/projects/samizdat/Go on, test in modern Firefox, Chromium, or Chrome.There are g-glitches every now and then, but basically once the ServiceWorker kicks in you should see a "YES" there on the example page. When you do, you should also notice the favicon appearing. That means IPFS is working; there is no favicon on that server!
(DIR) Post #9ntqntCFfcuXkAp4tM by pelican3301@mastodon.social
2019-10-06T18:15:57Z
1 likes, 0 repeats
@rysiek CensorSunk (as opposed to CensorShip)π
(DIR) Post #9o77mKjcWAIQAWD84G by rysiek@mastodon.social
2019-10-20T00:34:39Z
0 likes, 1 repeats
#Samizdat is moving forward nicely. We now have some basic explanation on the landing page, a nicer display of methods used to fetch content, and (just implemented, hot from the CI/CD pipeline!) info on which resources were fetched using which method.Check it out:https://cdn.test.occrp.org/projects/samizdat/Pretty sweet, if I may be so bold to say so!This is still Proof-of-Concept quality, and so many things can be done so much better. But it works already, in a way.So, yay!
(DIR) Post #9o77mLDOjS7Des8uTw by rysiek@mastodon.social
2019-10-20T00:37:19Z
0 likes, 1 repeats
For those new to the #Samizdat thing:1. if you want to test it, load it, and then reload it -- or even close the tab and open a new one to load it again; this way the ServiceWorker will kick in and stuff will start happening;2. it will not work without JS (sorry...), and it will not work in incognito/private mode.To those who had already looked at it: I would be super interested if your service worker kicked in! You might not get the full functionality until the service worker reloads.
(DIR) Post #9o77mLrSKW9rf6stv6 by rysiek@mastodon.social
2019-10-20T10:06:58Z
0 likes, 1 repeats
TFW you need to refactor your code to use a completely new (to you) technique of dealing with some particular problem, using technology you don't really feel that comfortable with......and 2h later stuff actually works:https://git.occrp.org/libre/samizdat/blob/58b5e20cb980233378385063b2a69d998672cc02/service-worker.js#L194I am very okay with this.Also, #Samizdat can now chain multiple delivery plugins. Which means I should now be able to implement caching using Caching API.
(DIR) Post #9o77mN27yKHxIUswC0 by dredmorbius@mastodon.cloud
2019-10-20T10:27:40Z
0 likes, 0 repeats
@rysiek TFW A Word you recognise starts showing up all over the place ;-)
(DIR) Post #9o79POhTo9jPiPOtfc by rysiek@mastodon.social
2019-10-20T10:45:55Z
0 likes, 0 repeats
@dredmorbius you brought it onto yourself, mah dude!
(DIR) Post #9oqnmbjVO0TkbeTw0W by rysiek@mastodon.social
2019-10-20T10:13:43Z
0 likes, 0 repeats
Do I have a ticket where I am tracking this, you ask?Why yes, yes I do:https://git.occrp.org/libre/samizdat/issues/16
(DIR) Post #9oqnmc3MCCMHbDlmwy by rysiek@mastodon.social
2019-10-22T22:27:13Z
0 likes, 0 repeats
Moar #Samizdat news: cache plugin implemented, but content not automagically pushed to local cache yet. You can test by:1. going to https://cdn.test.occrp.org/projects/samizdat/ , reloading so that ServiceWorker kicks in2. in JS console, run: await SamizdatPlugins[0].push(listLocalResources())3. once the flurry of activity ends, block cdn.test.occrp.org in /etc/hosts4. reload. should load immediately, and most resources should be marked as fetched from cache.
(DIR) Post #9oqnmcDzYeri8CkHWi by rysiek@mastodon.social
2019-10-22T22:30:13Z
0 likes, 0 repeats
Clearing cache is as easy as:await caches.delete('v1')Once you do that, while cdn.test.occrp.org is still blocked, you can reload the page and you should see #Samizdat load content (slowly...) from gun+ipfs.So! Now we have two plugins. π
(DIR) Post #9oqnmcSAhwCwqBNbd2 by rysiek@mastodon.social
2019-10-25T00:21:18Z
0 likes, 0 repeats
New in #Samizdat: implemented auto-caching of successful requests, and UIs for clearing the cache and publishing to Gun+IPFS. Check it out: https://cdn.test.occrp.org/projects/samizdat/I will need to make caching a bit less aggressive, and/or Gun a bit more patient in waiting for the *latest* version of a given resource IPFS address, but all in all, works pretty ok.
(DIR) Post #9oqnmcdW1lHXPMgfJI by rysiek@mastodon.social
2019-10-25T00:22:34Z
0 likes, 0 repeats
Also, some more UI niceness would be good -- displaying progress of pushing to Gun+IPFS, and informing user that cache has been successfully cleared, that sort of thing.
(DIR) Post #9oqnmcqzDg3c58zQJ6 by rysiek@mastodon.social
2019-11-10T00:43:33Z
0 likes, 0 repeats
Had a great long conversation with @tomasino about #Samizdat. Got some solid architectural advice. ππΎ Made fetch() into a plugin; we can now serve stuff from cache before a regular HTTP(S) fetch() goes out. Next steps include: - code cleanups - reimplementing how we store/access data about which URL was retrieved how - implementing a retrieve-from-cache-but-keep-fetching-in-background strategy so that a blocked site "loads" immediately, but the user still gets the fresh version eventually.
(DIR) Post #9oqnmdDfrKCnDVbXfc by rysiek@mastodon.social
2019-11-10T00:55:51Z
0 likes, 0 repeats
Also added some project status info and how to contact us on the landing page and in the README:https://cdn.test.occrp.org/projects/samizdat/My #Samizdat ToDo list still includes moving the project to a public Gitlab instance (0xacab.org probably, since it hosts a bunch of related projects including @sutty).I really need to do this soon, but it requires setting up the CI/CD pipeline in a new location (probably on my own server). And that's a bit of work.
(DIR) Post #9oqnmdQR5sPhr5ZjYu by rysiek@mastodon.social
2019-11-11T10:31:07Z
0 likes, 1 repeats
Oooof, some serious code cleanups and rewrites in #Samizdat this weekend: https://git.occrp.org/libre/samizdat/compare/v0.0.2-post-mozfest...8079ed31The tl;dr is: - regular fetch() is now also a plugin, which opens a number of possibilities; - any plugin that can locally cache requests and responses is now treated specially: the first such plugin is called after a successful content retrieval automagically;- if content is retrieved from cache, Samizdat continues trying to get it from a "live" source (fetch(), Gun+IPFS) in the background.
(DIR) Post #9oqnmdb4SKv8O4YE8e by rysiek@mastodon.social
2019-11-11T10:35:16Z
0 likes, 1 repeats
This last bit was suggested by @tomasino and turned out to be simpler to implement than expected. So, yay!To make #Samizdat a v1.0.0 that feels fully functional, we need to also: - rewrite the SamizdatInfo (keeping the information on which resource was fetched and how) thing; - add some fancy-shmancy UI displayed on any Samizdat-managed page; - which will together allow us to inform the user "hey, we got this from cache, but there seems to be fresher version; reload please".
(DIR) Post #9p1qwv3wbZ0L0I43Vo by rysiek@mastodon.social
2019-11-16T19:08:56Z
0 likes, 1 repeats
Okay #JavaScript people, riddle me this: in #Samizdat I have a #ServiceWorker and one or more browser window contexts (aka "clients) that might be using said ServiceWorker. I would like to pass some information between the two. Most importantly I would like to inform the relevant browser window that all the fetches that the ServiceWorker was handling on its behalf are done.Here's the ticket for more context https://git.occrp.org/libre/samizdat/issues/19
(DIR) Post #9p1qwvnfrXaHI7SZn6 by rysiek@mastodon.social
2019-11-16T19:12:08Z
0 likes, 0 repeats
Currently I am doing this by keeping the relevant information in Indexed DB. This has drawbacks: - data is the same for all browser windows, leading to potential confusion if there is more than one tab open using the ServiceWorker - there are no events to hook to catch when Indexed DB data changes, so it's down to setInterval() method, which is fugly.
(DIR) Post #9p1qwwCqLxiWYBEg1Q by rysiek@mastodon.social
2019-11-16T19:15:42Z
1 likes, 0 repeats
I *could* use Client API, specifically `postMessage` with `FetchEvent.clientId`, but clientId is not implemented on Safari (both Desktop and Mobile):https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/clientId
(DIR) Post #9p2KXvGlhDPD1x3kjg by rysiek@mastodon.social
2019-11-16T19:19:45Z
0 likes, 0 repeats
I *could* use MessageChannel API, but it requires setting up a channel between browser window and the SW, and there's no way to track which channel is used for which browser window.Plus, SW is quickly reaped, context destroyed, channel killed. On a new fetch() ServiceWorker restarts but the channel does not work, so a new channel would need to be set-up.But that can only happen from the browser window side, whereas only the ServiceWorker knows a fetch() has started.π π₯
(DIR) Post #9p2KXybRIoitMvkns8 by rysiek@mastodon.social
2019-11-16T19:23:19Z
0 likes, 0 repeats
I *still* could decide to use MessageChannel API, but would need to: - keep track in SW which fetch is from which referrer (not sure that's possible even; probably available in Request.Headers) - keep track which channel is for which URL/referrer - it would still get confusing if there are two tabs open with the same URP - and I would still need to do polling in setInterval() on browser window side, kinda defeating the purpose of the channel.
(DIR) Post #9p2KY1OQvd6O1SgxW4 by rysiek@mastodon.social
2019-11-16T19:27:35Z
0 likes, 0 repeats
So unless there is a way to hook an event in a browser window whenever a fetch() starts or when all fetch() events finish, MessageChannel API doesn't seem to be better than just using Indexed DB and polling it in setInterval() on a regularly.And so it doesn't seem it makes sense to use MessageChannel API at all, since either it's not effective, or clientId gets implemented in Safari soon and we should move to that.
(DIR) Post #9p2KY46opZnKRhTQye by rysiek@mastodon.social
2019-11-16T19:30:23Z
0 likes, 0 repeats
But if I'm to re-implement the Samizdatinfo on clientId now, I need a sane graceful degradation strategy for Safari.But perhaps I am overthinking this? Perhaps the only event I need is onload. At that point I'll know already if the page is loaded from cache or not, and can display a relevant message to the user ("cache in use, try reloading"), perhaps after a sane timeout (letting the secondary fetch() in SW try to finish).
(DIR) Post #9p2KY6qceFcawKv2eG by rysiek@mastodon.social
2019-11-16T19:32:33Z
0 likes, 0 repeats
So perhaps that's my graceful degradation strategy for Safari (and whatever else doesn't support FetchEvent.clientId)? It will not be able to handle other resources (like iframes or whatnot) very effectively, but it'll be better than nothing. And probably better than what we have now anyway.
(DIR) Post #9p2KY9GDg3HkQIuVpA by rysiek@mastodon.social
2019-11-16T20:09:11Z
0 likes, 0 repeats
Or perhaps MDN is wrong and #Safari supports Client API?https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/Many confus.
(DIR) Post #9p2KYCBMoYBbU7fBB2 by rysiek@mastodon.social
2019-11-16T23:00:32Z
0 likes, 0 repeats
Well we have a branch now: https://git.occrp.org/libre/samizdat/tree/wip-message-passing
(DIR) Post #9p2KYEj7M2N7NNTA3s by rysiek@mastodon.social
2019-11-17T00:14:49Z
0 likes, 1 repeats
Proof-of-Concept of the new signalling system done without removing the old one.Can anyone test on Safari please? Open a new tab, open the JS console, and navigate here:https://cdn.test.occrp.org/projects/samizdat/index.htmlThen, reload (so that the service worker kicks in); you should see "ServiceWorker: yes" in orange.Make sure that you see this commit ID in the console and in both places at the page bottom: c223b08cIf all of this is true, check if in the console you have messages saying: "SamizdatInfo received!"
(DIR) Post #9p6Tv1lTOCTw3ULxPk by rysiek@mastodon.social
2019-11-19T00:41:55Z
0 likes, 1 repeats
Done some serious work on #Samizdat. Fixed some bugs, almost finished implementing the new messaging system (based on client.postMessage() in the end), ripped the old Indexed DB-based system out completely. Introduced new bugs to fix next.Merge request here:https://git.occrp.org/libre/samizdat/merge_requests/13Still work in progress though.
(DIR) Post #9pX1ZkYcjMG35l4VVI by rysiek@mastodon.social
2019-11-20T00:53:18Z
0 likes, 0 repeats
Merged! #Samizdat now uses message passing instead of Indexed DB for ServiceWorker to inform the window clients of things. I CAN HAZ nice things, liek: - info that a resource was fetched from cache, but fetching it via Gun+IPFS is running in background; - near-instant info on resources being fetched and status of that; - info when all resources get initially fetched (in the future this is when "stuff fetched from cache, but newer versions available, reload please" message will be displayed).
(DIR) Post #9pX1ZktBUuhk7WgvYG by rysiek@mastodon.social
2019-11-20T00:57:06Z
0 likes, 0 repeats
The Merge Request of Doom:https://git.occrp.org/libre/samizdat/merge_requests/13Try #Samizdat here:https://cdn.test.occrp.org/projects/samizdat/You might need to reload the service worker (refer to browser docs). Automagic reloading of the service worker code will come... one day, inshallah!Also, probably doesn't work on Safari, because crapple refuses to implement things. Graceful degradation will come... one day, inshallah!
(DIR) Post #9pX1ZlHe1yGpLO8Sg4 by rysiek@mastodon.social
2019-11-20T01:14:02Z
0 likes, 0 repeats
So I guess the roadmap to #Samizdat 1.0-beta would be something along the lines of: - fix the issues (like caching plugin use is double-counted; when reloading soon after a load there is no indication how/where the resources were loaded from); - implement the "stuff loaded from cache but newer content available, reload to see" message; - cleanup the browser window / UI side of things so that it's easy to include on any site.A *lot* of work, but hey, now at least we kinda have a roadmap!
(DIR) Post #9pX1ZloG4iMGyXOVVo by rysiek@mastodon.social
2019-12-01T14:07:52Z
0 likes, 0 repeats
Ok, back to playing with #Samizdat after some traveling. - caching plugin not double-counted anymore; - finally there is a proper project website at https://samizdat.is/Need to fix Gun+IPFS for the new domain, today is a good time.Main project home still https://git.occrp.org/libre/samizdat/ for the time being, but hoping to move it to a public GitLab instance soon.
(DIR) Post #9pX1ZmHKKdbuQgzioy by rysiek@mastodon.social
2019-12-01T20:02:15Z
0 likes, 1 repeats
Ok, we have the #IPFS and Gun daemons deployed on the new server for #Samizdat, and content for https://samizdat.is/ pushed to IPFS and Gun.That means now when you load the site in Firefox you should get the favicon. Favicon does not exist on the server, but exists in IPFS, for the purpose of testing all works.In Chrome/Chromium it should show up after a reload or two (take your time though, Chrome/Chromium caches things in weird ways).
(DIR) Post #9pgkriTsR8xNSX5Rj6 by rysiek@mastodon.social
2019-12-02T18:43:37Z
0 likes, 0 repeats
Oh boy, the #Samizdat CI/CD pipeline at 0xacab.org did not work because I did not enable it in project settings. #PEBKAC! π€¦ββοΈ But ow it works! So we have the first successful deploy of https://samizdat.is/ from its new git home:https://0xacab.org/rysiek/samizdat/-/jobs/117602Woo! That means our migration of Samizdat is complete. It's on it's own domain, and on an open GitLab instance. π :pensive_party_blob: π
(DIR) Post #9pgkrird0pxIeCCPkO by rysiek@mastodon.social
2019-12-02T19:27:25Z
0 likes, 0 repeats
One of the Big Issues I will have to solve before #Samizdat becomes really useful is measuring usage. I even have an issue for that!https://0xacab.org/rysiek/samizdat/issues/27tl;dr: there needs to be a way to measure how many times Samizdat made it possible to circumvent censorship.That's something that will have to run on reader's browser, and so there are serious privacy considerations.But without being able to show it works, it will be hard to convince people (and site admins) it does.
(DIR) Post #9pgkrjAlrfGfbZ9haK by rysiek@mastodon.social
2019-12-04T18:41:40Z
0 likes, 0 repeats
In the meantime, working on cache invalidation for #Samizdat. One of the Two Hard Problems in IT (cache invalidation, naming things, and off-by-one errors)!Anyway, trying to keep some context in cache using "x-samizdat-*" headers. But the Cache API doesn't seem to cache all headers, just some:https://0xacab.org/rysiek/samizdat/issues/25#note_292141Of course, there is no mention of it anywhere in the docs (or I have not found it after hours of looking).*sigh*
(DIR) Post #9pgkrjTuiUa2Yw6zQG by rysiek@mastodon.social
2019-12-06T02:00:56Z
0 likes, 0 repeats
I *think* I figured out how to do cache invalidation in #Samizdat in a more-or-less sane way, *assuming that* only a single live plugin is in use.I might have an idea how to do it across plugins too.Relevant branch here:https://0xacab.org/rysiek/samizdat/tree/wip-cache-invalidation
(DIR) Post #9pgkrjmLbxKFU6ji9g by rysiek@mastodon.social
2019-12-06T12:33:07Z
0 likes, 0 repeats
Boom! Cache (or, rather, locally stashed version) invalidation implemented in #samizdat https://0xacab.org/rysiek/samizdat/merge_requests/14From now on if you visit the site once load the current Service Worker, stuff gets stashed, and then when you happen to visit the site on a blocked connection, it is *assumed* Gun+IPFS version is fresher.If you visit again, and have the Gun+IPFS version stashed, IPFS addresses are compared to check freshness.If a fresh version is available, a message is displayed to the reader.
(DIR) Post #9pgkrk92FbTQcTLpWC by rysiek@mastodon.social
2019-12-06T12:36:01Z
1 likes, 0 repeats
I have to figure out how would a demo page for this #Samizdat stash invalidation thing look.In the meantime, CI/CD pipeline succeeded, and so #Samizdat stash invalidation is deployed to https://samizdat.is/π
(DIR) Post #9rPCjTbHjrCBerQO1Y by rysiek@mastodon.social
2019-12-06T13:56:40Z
0 likes, 0 repeats
What's the difference between a "cached" and "stashed" resource in #Samizdat, you ask? Excellent question!There can be multiple Samizdat plugins that implement the basic idea of keeping a version of a resource locally. One plugin currently implementing this is called "cache" and uses the Cache API:https://0xacab.org/rysiek/samizdat/blob/master/plugins/cache.jsSo, to avoid confusion, whenever I'm talking in general about keeping versions locally, I will call it "stashing".This will be made clear here: https://0xacab.org/rysiek/samizdat/blob/master/ARCHITECTURE.md
(DIR) Post #9rPCjU5luVa9BPgjXk by rysiek@mastodon.social
2019-12-06T14:05:53Z
0 likes, 0 repeats
Oh, did I already say there's a Beta milestone for #Samizdat now, too? Well, there is:https://0xacab.org/rysiek/samizdat/-/milestones/1A few more issues will be added soon. Including documentation. Yes, you heard that right! There's going to be some documentation, inshallah!
(DIR) Post #9rPCjUYUBkYCcT7fIe by rysiek@mastodon.social
2019-12-08T11:09:42Z
0 likes, 0 repeats
Worked on the documenation for #Samizdat a bit. Also, started working on implementing the standalone interface. MR: https://0xacab.org/rysiek/samizdat/merge_requests/15The idea is to have the basic interface defined in samizdat.js so that all an admin needs to do is include that file. Currently the interface is tightly tied to index.html.
(DIR) Post #9rPCjUzQZa6Ly1jBIG by rysiek@mastodon.social
2019-12-10T01:28:43Z
0 likes, 0 repeats
And we now have a standalone user UI in #Samizdat:https://0xacab.org/rysiek/samizdat/merge_requests/15Check it out here:https://samizdat.is/Or here, to see it on a page that does not use the regular Samizdat CSS:https://samizdat.is/debug.htmlThe UI only shows up if there are resources that seem to be unavailable via HTTPS (on samizdat.is that's the case with the favicon).The only thing that needs to be included by website admins is a single JS file (samizdat.js).Next step: creating a standalone admin UI.
(DIR) Post #9rPCjVUchb3TWmK5uy by rysiek@mastodon.social
2019-12-10T13:06:23Z
0 likes, 0 repeats
And about the Beta milestone of #Samizdat, added some tickets, including related to documentation:https://0xacab.org/rysiek/samizdat/-/milestones/1Contributions welcome!
(DIR) Post #9rPCjW3ib77zHck7cW by rysiek@mastodon.social
2019-12-15T13:59:34Z
0 likes, 0 repeats
Had a good discussion about #Samizdat with @tomasino last night. I love it when I get to rubber duck things and it turns out they're simpler than I thought.Like measuring usage:https://0xacab.org/rysiek/samizdat/issues/27It *seems* like it's complicated, until it becomes clear that 3rd party tracking is not going to be affected by most website blocking scenarios. So the only thing that needs to be handled is when a website is using log analytics or their own tracker.
(DIR) Post #9rPCjWYYkRnWpHAkgy by rysiek@mastodon.social
2020-01-10T02:06:34Z
0 likes, 0 repeats
Working on simplifying #Samizdat deployment, relevant ticket: https://0xacab.org/rysiek/samizdat/issues/32And the relevant merge request:https://0xacab.org/rysiek/samizdat/merge_requests/16Did some code cleanup, and the samizdat-cli now can get a user's pubkey (will be needed later), and *almost* register a new Gun user.More fun soon!
(DIR) Post #9rPCjX7IfHaSZ1QUqG by rysiek@mastodon.social
2020-01-12T01:21:20Z
0 likes, 0 repeats
Working on implementing some basic user management in #Samizdat's samizdat-cli, as a necessary foundation for more sane deployment procedure. Relevant ticket and merge request:https://0xacab.org/rysiek/samizdat/issues/34https://0xacab.org/rysiek/samizdat/merge_requests/16Almost works, but for *some* reason users created using it are unusable. Specifically, it seems impossible to auth() as them. Moar debugging tomorrow. *sigh*
(DIR) Post #9rPCjXfKckoEGZLft2 by rysiek@mastodon.social
2020-01-12T13:35:24Z
0 likes, 0 repeats
I have no clue what's wrong with my #Samizdat CLI code. When I create a user using samizdat-cli, it's impossible to auth() as that user (neither using the CLI, nor in a browser window):https://0xacab.org/snippets/799But if I create a user using the same functions in a browser window, all works fine. I can then auth() as that user both in the browser window *and* via the CLI.Relevant (fugly!) code here:https://0xacab.org/rysiek/samizdat/blob/wip-gun-user-management/samizdat-cli/bin/samizdat.js#L456
(DIR) Post #9rPCjY3RB85jTKcvSa by rysiek@mastodon.social
2020-01-12T13:40:03Z
0 likes, 0 repeats
Is this relevant? Who knows! https://github.com/amark/gun/issues/478
(DIR) Post #9rPCjYNdy0FqU053xI by rysiek@mastodon.social
2020-01-24T18:50:12Z
0 likes, 0 repeats
Seems like Gun has some bugs when running from #NodeJS. This is affecting #Samizdat (and is in fact the reason why development is not really moving right now).I've reported one bug already:https://github.com/amark/gun/issues/891More to come.Oh, did I write a test harness just for that? Yes. Yes I did:https://github.com/rysiekpl/gun-nodejs-bugs(GitHub because Gun is hosted there; personally I prefer unifficial Gitlab instances, obviously)
(DIR) Post #9rPCjYkgaKgbdSrSs4 by rysiek@mastodon.social
2020-01-24T18:56:09Z
0 likes, 0 repeats
I have a few things I can focus on in #Samizdat once I report all the NodeJS-related bugs (and before they get fixed).I am very tempted to finally write the IPFS/IPNS plugin (completely side-stepping Gun), or a dat:// plugin. But perhaps I should do some boring stuff from the Beta milestone?https://0xacab.org/rysiek/samizdat/-/milestones/1So, a poll! What should I focus on in Samizdat?
(DIR) Post #9rPCjZFAkz4ZA17oOG by kravietz@social.privacytools.io
2020-01-26T21:24:13Z
0 likes, 0 repeats
@rysiek I did vote for DAT because I like and run a whole website from homebase (dat://ssb.webcookies.pub) but seeing interest in the project being minimal I'm not very optimistic.
(DIR) Post #9rPF4f4EV3aVDBC6IS by rysiek@mastodon.social
2020-01-26T21:50:30Z
0 likes, 0 repeats
@kravietz yeah, but dat:// is already implemented in a browser, right? Beaker, was it?
(DIR) Post #9rPFHM7eFQwQDfqRNo by kravietz@social.privacytools.io
2020-01-26T21:52:49Z
0 likes, 0 repeats
@rysiek it is and it works like a charm, except... you need a separate browser to benefit from itThere's an add on for FF but it essentially starts Beaker on DAT page
(DIR) Post #9rPFQ3Q39gvQopbFOi by rysiek@mastodon.social
2020-01-26T21:54:24Z
0 likes, 0 repeats
@kravietz right. But dat:// has a JS implementation, no?
(DIR) Post #9rPHtXSuitSOJO7u0u by kravietz@social.privacytools.io
2020-01-26T22:22:07Z
0 likes, 0 repeats
@rysiek Yes it's all JS libraries https://github.com/beakerbrowser/homebase
(DIR) Post #9rPIP18WSMzRJPbBEe by rysiek@mastodon.social
2020-01-26T22:27:49Z
0 likes, 0 repeats
@kravietz ah yes. So I remembered correct, which means I can add it to #Samizdat.
(DIR) Post #9wpeqk6VTigSwVRMie by rysiek@mastodon.social
2020-01-27T23:22:33Z
0 likes, 0 repeats
And so, the People have spoken. I'll bump implementing dat:// up on the ToDo list for #Samizdat. However, for Beta I really need to have documentation and Admin UI I guess. Eh.
(DIR) Post #9wpeqkLOaMarggPFvU by rysiek@mastodon.social
2020-02-01T13:15:54Z
0 likes, 0 repeats
Yesterday I noticed #Samizdat is not working. Spent most of the day debugging. Turns out four things happened at the same time: - major code changes on my side - some code changes on Gun side - Samizdat stopped using the test Gun instance run by @OCCRP - the public Gun peer started deleting stuffOoof! This was pretty damn annoying to deal with, but all is well again. As an added bonus: - there is a Gun peer running at samizdat.is - got an idea how to simplify deployment significantly.
(DIR) Post #9wpeqkZviKDgPlCra4 by rysiek@mastodon.social
2020-02-01T13:22:04Z
0 likes, 0 repeats
I am also more and more considering moving #Samizdat away from Gun. Gun is currently used to map from a well know address ( Gun user pubkey) to the content-adressed resources in IPFS. This can be done using #IPNS.So far my experience with Gun has been bumpy. It seems a bit easier to use than IPNS, but with all the trouble I've had with it... not sure it's worth it.I'll probably develop gun+ipfs plugin a tiny bit more, and then move focus to IPNS/IPFS. Added benefit: fewer dependencies.
(DIR) Post #9wpeqlhPXznXtFiLse by rysiek@mastodon.social
2020-02-02T13:33:41Z
0 likes, 0 repeats
Oh look, somebody had a similar idea to #Samizdat: https://github.com/gozala/lunetI need to research this and check how our approaches differ and what are the similarities. Good to know!
(DIR) Post #9wpeqmF5WmjjZhTFNA by rysiek@mastodon.social
2020-02-02T13:49:57Z
0 likes, 0 repeats
Had a good chat with Sam from dat:// project about #Samizdat. Got a bunch of good input and great links (including the lunet thing).Good news: dat:// protocol v2 has a bunch of improvements and is almost ready for being released.Bad news: dat:// v2 is incompatible with v1, has no pure JS implementation, and it's unlikely it will get one soon.Ugly news: this means it most likely doesn't make much sense to implement dat:// in #Samizdat at this moment.
(DIR) Post #9wpeqn20atru1QMJcm by rysiek@mastodon.social
2020-02-02T14:43:26Z
0 likes, 0 repeats
Ok, so it might in fact make sense to implement dat:// in #Samizdat, since the API is not expected to change between v1 and v2.Decisions, decisions!In the meantime I will just procrastinate and somehow display the #Samizdat hashtag on samizdat.is, because why not:https://0xacab.org/rysiek/samizdat/issues/44
(DIR) Post #9wpeqnttMYyCiXZLc0 by rysiek@mastodon.social
2020-07-06T22:07:16Z
0 likes, 1 repeats
Many thanks to @syntax for his contribution to #Samizdat:https://0xacab.org/rysiek/samizdat/-/merge_requests/22This is a much-needed nudge for me to get back to hacking on this project. :blobcat:
(DIR) Post #9wpeqoGa0D7NquBSyW by syntax@social.privacytools.io
2020-07-07T05:02:15Z
0 likes, 1 repeats
@rysiek Happy to help, and good luck with your demos!
(DIR) Post #9zMLDddtpnGM6ByZG4 by rysiek@mastodon.social
2020-09-08T12:55:27Z
0 likes, 0 repeats
I have taken a way-too-long sabbatical from working on #Samizdat, but finally getting back into it.First step (making sure pipelines work again) was easier than expected: my #GunJS superpeer was down. All green:https://0xacab.org/rysiek/samizdat/-/pipelines/43312New documentation-related issues to work on:https://0xacab.org/rysiek/samizdat/-/issues/54https://0xacab.org/rysiek/samizdat/-/issues/53And need to improve how the pipeline verifies stuff is available in IPFS, pretty sure the 504s there are because we get throttled by gateways:https://0xacab.org/rysiek/samizdat/-/jobs/163615#L211
(DIR) Post #9zMLDdr131kqks72hc by rysiek@mastodon.social
2020-09-18T00:10:07Z
0 likes, 0 repeats
I noticed that until now I have not added a #CodeOfConduct to #Samizdat.That oversight has just been fixed:https://0xacab.org/rysiek/samizdat/-/commit/17c31bcc21a1a909e3f3ab13f763bde40cf11247
(DIR) Post #9zMLDdyoa1zd93lGrI by rysiek@mastodon.social
2020-09-20T16:50:05Z
0 likes, 0 repeats
Work on the #Samizdat overview document is proceeding nicely and I am starting to be pretty happy with it:https://0xacab.org/rysiek/samizdat/-/blob/wip-documentation/docs/OVERVIEW.mdOn friend's advice I shortened the Philosophy section substantially, and expanded on it in a separate document:https://0xacab.org/rysiek/samizdat/-/blob/wip-documentation/docs/PHILOSOPHY.mdAs always, comments, suggestions, and patches welcome!
(DIR) Post #9zMLDeGtUoSG38Di2S by rysiek@mastodon.social
2020-09-20T17:58:13Z
0 likes, 0 repeats
#Samizdat overview now has flowcharts:https://0xacab.org/rysiek/samizdat/-/blob/wip-documentation/docs/OVERVIEW.md#use-casesI have no idea if they're useful. Only one way to find out!
(DIR) Post #9zMLDeW8a8eEoPLsnY by wolf480pl@mstdn.io
2020-09-20T19:12:00Z
0 likes, 0 repeats
@rysiek the flowcharts let me understand how Samizdat works in the big picture without ever reading any of the text (be it docs or source code)
(DIR) Post #9zMLHOhVKVaguqSEj2 by alcinnz@floss.social
2020-09-20T19:12:38Z
0 likes, 0 repeats
@wolf480pl @rysiek Related link I was just pointed to: http://akkartik.name/post/readable-bad