Call for Co-Creation Bootcamp: Improving civic participation with emerging technologies - Observatory of Public Sector Innovation
"We are looking for developers, designers, researchers, or technologists to join public sector teams to jointly create solutions to civic participation challenges in our co-creation bootcamp in Lisbon from 26 to 27 February 2025."
https://oecd-opsi.org/blog/call-for-co-creation-bootcamp/
Call for Co-Creation Bootcamp: Improving civic participation with emerging technologies - Observatory of Public Sector Innovation
"We are looking for developers, designers, researchers, or technologists to join public sector teams to jointly create solutions to civic participation challenges in our co-creation bootcamp in Lisbon from 26 to 27 February 2025."
https://oecd-opsi.org/blog/call-for-co-creation-bootcamp/
So, if nick exist on feed, great, use it! if it doesn't, assign a random hash derived from whole URL as nick. Done. :-D
I'd rather prefer to get it from the mentioned .txt nick metadata (could be cached for performance).
So my vote would to make it mandatory to follow
@<name url> but only using that name/nick if the URL doesn't contain another nick.A main advantage is that when the destination URL changes the nick, it'll be automagically updated in the thread view (as happens with some other microblogging platforms, following the Jakob's Law)
prosoalIs it a typo of Proposal right? =P (Genuinely asking)=
@nick@domain thing that yarnd invented) and be done. It's really that simple.When yarnds peer with each other, the odds of actually having come across that feed URL in the past are higher than with traditional clients that only have their local set of subscribed feeds. One additional improvment would be to also look at all the mentions and see if somebody used a nick for that URL and go with that.
Yeah, yarnd currently renders some really weird shit when the mention contains just a URL, but I'd call that a bug for sure.
Personally, I do not like the
@nick@domain syntax at all. It looks silly to my eyes. What might have also contributed is the fact of this mentions syntax gotten screwed up so many times by yarnd in the past. But that's a totally different topic.
"Will now retire to my room with last weekend's newspapers and their fiendish crossword puzzles and spend the morning 'enjoying poor health,' as my mother used to say."
"Will now retire to my room with last weekend's newspapers and their fiendish crossword puzzles and spend the morning 'enjoying poor health,' as my mother used to say."
https://en.wikipedia.org/wiki/84,_Charing_Cross_Road 
https://en.wikipedia.org/wiki/84,_Charing_Cross_Road 
Twt Subject extension is implemented in yarnd and now apparently jenny 🤣🤣 Where it strips out the subject from the displayed/rendered content. Which is what you want... But oh well haha 😆
Twt Subject extension is implemented in yarnd and now apparently jenny 🤣🤣 Where it strips out the subject from the displayed/rendered content. Which is what you want... But oh well haha 😆
yarnd are stored under /path/to/data under the feeds directory. Oner per user.
yarnd are stored under /path/to/data under the feeds directory. Oner per user.
> Was there ever a reason to do that? 🤔
I'm not sure to be honest. I have no idea why you'd ever want to do a "nameless" @-mention.
As an aside, if we could all agree, I'd personally just say we scrap this whole fragile broken shit and bring out WebMentions and be done with it. And then mentions are always
@nick@domain and looked up, cached and can never be screwed up haha 🤣
> Was there ever a reason to do that? 🤔
I'm not sure to be honest. I have no idea why you'd ever want to do a "nameless" @-mention.
As an aside, if we could all agree, I'd personally just say we scrap this whole fragile broken shit and bring out WebMentions and be done with it. And then mentions are always
@nick@domain and looked up, cached and can never be screwed up haha 🤣
> What’s the motivation for deprecation?
Namely that without the mention having a label (_as such_) it becomes very hard to render it in any sane/nice way. I think we should just stick to
@<label url> personally. It makes implementations have to worry about far less edge cases.
> What’s the motivation for deprecation?
Namely that without the mention having a label (_as such_) it becomes very hard to render it in any sane/nice way. I think we should just stick to
@<label url> personally. It makes implementations have to worry about far less edge cases.
Makefile or something. I'm not sure what version @kat built/deployed from? 🤔🤔 -- Also I need to release v2.0 soon™
Makefile or something. I'm not sure what version @kat built/deployed from? 🤔🤔 -- Also I need to release v2.0 soon™
# This is hosted by a Yarn.social pod yarn running yarnd ERSION@OMMIT go1.23.4
^^^^^^^^^^^^
Looks like the first letters of the version and commit got somehow chopped off. I've no idea what happened here, maybe @prologic knows something. :-? I'm not familiar with the templating, I just recall @xuu reporting in IRC the other day that he's also having great fun with his custom preamble from time to time.
That "broken" comment doesn't hurt anything, it's still a proper comment and hence ignored by clients. It's just odd, that's all.
https://movq.de/v/6ec68b50dd/los86-edit-shell.mp4
Trivial to implement but super useful. It allows for simple but meaningful dev cycles: Edit source code, run/test it, back to editor. That’s what I do in the video.
(The Brainfuck program is silly, but I got nothing else at the moment.)
The I/O cache is also getting better. All that back and forth doesn’t hit the disk at all, once cached.
This whole thing is much more fun and interesting when you run it from a real floppy disk. It’s a 5.25" floppy in the video (so it’s *actually* _floppy_ 😅). Disk seek times can be *catastrophic* and you don’t notice any of this on modern disks.
https://movq.de/v/6ec68b50dd/los86-edit-shell.mp4
Trivial to implement but super useful. It allows for simple but meaningful dev cycles: Edit source code, run/test it, back to editor. That’s what I do in the video.
(The Brainfuck program is silly, but I got nothing else at the moment.)
The I/O cache is also getting better. All that back and forth doesn’t hit the disk at all, once cached.
This whole thing is much more fun and interesting when you run it from a real floppy disk. It’s a 5.25" floppy in the video (so it’s *actually* _floppy_ 😅). Disk seek times can be *catastrophic* and you don’t notice any of this on modern disks.
https://movq.de/v/6ec68b50dd/los86-edit-shell.mp4
Trivial to implement but super useful. It allows for simple but meaningful dev cycles: Edit source code, run/test it, back to editor. That’s what I do in the video.
(The Brainfuck program is silly, but I got nothing else at the moment.)
The I/O cache is also getting better. All that back and forth doesn’t hit the disk at all, once cached.
This whole thing is much more fun and interesting when you run it from a real floppy disk. It’s a 5.25" floppy in the video (so it’s *actually* _floppy_ 😅). Disk seek times can be *catastrophic* and you don’t notice any of this on modern disks.
https://movq.de/v/6ec68b50dd/los86-edit-shell.mp4
Trivial to implement but super useful. It allows for simple but meaningful dev cycles: Edit source code, run/test it, back to editor. That’s what I do in the video.
(The Brainfuck program is silly, but I got nothing else at the moment.)
The I/O cache is also getting better. All that back and forth doesn’t hit the disk at all, once cached.
This whole thing is much more fun and interesting when you run it from a real floppy disk. It’s a 5.25" floppy in the video (so it’s *actually* _floppy_ 😅). Disk seek times can be *catastrophic* and you don’t notice any of this on modern disks.
tt currently supports all three forms: @<nick url>, @<url> and even the illegal @<nick>. The difference between the last two is whether the token in angle brackets looks like a URL or not. Whenever a nick is available, the nick is rendered. In case there is just a URL, it tries to resolve the nick from the subscriptions. If that also does not work, it displays the URL.