hpr-knowledge-base/hpr_transcripts/hpr4411.txt

Episode: 4411
Title: HPR4411: The Pachli project
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4411/hpr4411.mp3
Transcribed: 2025-10-26 00:27:20

---

This is Hacker Public Radio episode 4,411 for Monday the 30th of June 2025.
Today's show is entitled The Patchly Project.
It is part of the series interviews.
It is hosted by the Love Bug and is about 72 minutes long.
It carries a clean flag.
The summary is Dave and Kevvie interview Nick from The Patchly Project.
Hello and welcome to another exciting episode of Hacker Public Radio.
My name is Dave and I'm joined this time around by Kevvie.
Hello, hello.
Everybody knows who Kevvie is from the, well, many episodes he puts out plus also the
monthly community news as well.
So on this particular episode, we are going to be talking to Nick from The Patchly Project.
And rather than me actually going through and explaining what Patchly is, I thought I
would pass over to Nick to explain.
Before we do that, Nick, welcome.
Thank you so much for joining us.
Can you just give us a little bit, a little bit of information about you, who you are,
and your development background?
Thank you very much.
So I am, old time, I would say, open source developer, cutting my teeth on open source
unique systems back in the 1990s, free BSD, at that point was my system of choice back
in university, and somehow managed to parlay that into a bit of a career when the internet
was beginning to take off in the sort of the 1990s in the UK.
And then for the past almost 20 years, I've been based out in Switzerland, working with
different companies out here, and a couple of you, well, almost two years ago, now I started
the Patchly Project with, and I sort of consider myself to be in the role of sort of steward
of that project.
So with a sort of this specific idea that people will come after to continue the work.
Excellent.
Well, thank you for that.
So I suppose the next logical question is, what is Patchly?
So Patchly is a client for Masterland and other servers on the Fediverse that support the
Masterland client API.
It is for Android devices going back as far as API version 23, which if I thought about
it, I would actually be able to talk about what Android version that corresponds to.
But yeah, these devices, like 10 years old, all they're about, up to the present day.
Right.
Um, what is Patchly, was, was the name come from?
Ah, so I mean, this is one of the most probably difficult decisions when you're starting an
open sort of project is trying to come up with the name, and I remember I spent a good sort
of 10 days to two weeks brainstorming different ideas in an obsidian notebook, as they would
sort of come to me.
And then you go through this whole process of, well, I can't use that because it's somebody
else's trademark, or I can't use that because it is a dirty word in some language that
I'd never heard of before.
So you sort of, you go through this whole process and you whittle the list down to sort
of three or four.
Um, and then Patchly sort of stuck with me for a couple of reasons.
Um, one is, uh, it's derived from, uh, Pacidum and a lot of, like, sort of mastered and related
projects use elephant imagery in some form or another.
And then the L.I. suffix is a particular feature of Swiss German.
So it's a sort of a nod to, uh, where I'm living now.
Um, you might, you see this in some other open source projects, uh, they're also started
around this area.
So there's the, um, Broadly and Zopfle compression algorithms, um, where Broadly, um,
brought bread, so Lee, like a little piece of bread or like a little bun or something,
um, in there.
And then sort of what sealed it for me was when I was trying to come up with logo ideas
and realize that a sort of a stylized capital P, if you look at it in a particular light,
looks like an elephant's head facing left with sort of the stem of the pea being the
trunk and the, um, I don't know what the type of harmful term for it is, but the sort
of the cup terrier of the round right being, yeah, the, um, the big round bits at the
top is critical.
Uh, yes.
So that's on the technical.
Do we need to?
Yeah.
So, so when I sort of looked at that, sort of all of these pieces came together and it
was like, yeah, okay, that, that will absolutely do.
Oh, fantastic.
Okay.
Uh, I think that's probably the, the one thing that had I not researched it, uh, I would
be curious as to where the name came from.
It was like you quietly said, the name of something is what the entire thing hangs off of.
Um, um, okay.
So the market at the moment is, is quite, um, I wouldn't say saturated, but it's quite
well provisioned for, uh, with mastodon and Fediverse, uh, enable clients, particularly
for the Android platform.
What prompted you to create a new application to service the Fediverse?
So I think some of this is down to, um, software that I was sort of previously familiar with
and the aesthetics of that.
So when I first started, um, uh, and joined, uh, I mastered and server and this was around
mid-22, I think.
Um, so I was coming from Twitter, so I was part of that, uh, Exodus at that point and was
looking around for different Android clients to use and quite quickly bounced off the official
mastodon app.
Um, I sort of no shade on that app and the developer there, but the, the UI, um, that it has
just sort of didn't work for me.
I was familiar with the, uh, Twitter open source Twitter client, um, and it sort of, it
didn't behave like that and there were bits about the UI, um, that, for whatever reason,
like didn't suit me, similarly with, um, another, I believe, like sort of very good app,
uh, Fedilab, um, and then I eventually found the Tusky client, um, which I used for about
a year.
And in the course of that year, also then started, uh, contributing, uh, to that project,
um, in the last, like, sort of eight months before the packet project started, I think
I ran two of the Tusky releases and was, like, sort of, replying to user support questions
from the Tusky account and things like that, um, and then, uh, aspects of how the Tusky
project was being run, um, and, like, this is probably not the place to relish against
any of that, um, sort of didn't sit well with me and sort of my philosophies around,
like how open source projects should be run, um, so I sort of left that project and we're
still then using Tusky on a regular basis, but we're seeing all of these things that
I wanted to, uh, change, like, either they were bugs or features that I wanted to add
or whatever.
I thought, right, well, then the, the best way to do this, um, is to, uh, then fork, uh,
that project.
Um, and if I'm going to be raising issues around things like open source project
governance and best practices and so on, it's one thing to be able to talk about that,
but I should also then be prepared to actually put those practices in practice.
I guess, and actually demonstrate yet that, uh, yes, this is a realistic and feasible
way to run an open source project, um, so that would be, um, quite a, quite apart from
any of the project governance, uh, type of issues.
This is things like having a, uh, a regular release process so that people who are contributing
to the project know when their contributions are going to be in the hands of people using,
uh, the application, things like that.
Okay.
That does make a lot of sense and I, I personally quite appreciate the, the non-functional,
uh, attention that you're obviously, uh, putting into this project.
Um, I want to touch on that a bit more in a moment, but I think my, my last question
with regards to, um, the end user side of pack liars and app is, what's pack liars
us pay?
Uh, I understand that's quite a provocative question, but what would, what would make,
wake me as a user or as somebody who is going to join the Fediverse for the first time?
Why would they use pack li?
That's a great question.
Um, I think if there's probably a number of different angles to that, I think depending
on what you as a user, um, care about, uh, so one might be the, uh, the general aesthetic
was sort of look and feel of the app.
So the UI, um, quite deliberately does not follow some of the, the latest, uh, like UI trends,
like the very newest, uh, Google material libraries, for example, because I personally, um, don't
get on with those terribly well.
Um, and I know I'm sort of not the only person, um, that's like that.
And this idea of like sort of the app, UI, changing very regularly to sort of chase these
latest trends, um, I think can be of put into people.
If you are somebody who has, uh, particular accessibility requirements from a Fediverse
client, then that is one of the things, uh, that I focused on quite heavily.
I've been quite fortunate to have, uh, a number of, uh, users who have different accessibility
needs, who have been very gracious with their time and explaining where, um, aspects of
the app sort of don't work for them.
I'm being, I'm providing quite detailed feedback on if you did this or if the app behaved
in this particular way or whatever, it would be more accessible to us.
And then that carries through into, um, new, uh, feature design, uh, or improvements to
the UI.
So one of the things, for example, that shipped in the most recent release was a significant
UI change when you're writing a new post and you attach media to that post, where previously
a user who had to do that.
And this is pretty common across all of the client apps, um, at the moment is you attach
the media and then you have to tap multiple times before you get to the bit of the UI that
lets you provide the caption for that media, um, that is particularly useful to people
who have different sort of accessibility needs.
And based on feedback from them and my own use, one of the things that the new version
now does is when you attach media to a post you get within the main UI, the fields to,
uh, provide the caption immediately.
There's no having to click around the UI, um, if you don't know even that providing captions
is a good practice on the video as you might not even know to, to look for that.
So things like that, um, I think are important.
If you are a user who regrettably, um, faces, uh, forms of harassment online, then patty
contains controls that I don't think any other client has, um, to not remove the, uh,
harasses, um, but certainly to help minimize the impact of that when young in some cases
prevent you from saying it.
So patty has controls, for example, to, that you can turn on to prevent you saying, say,
a notification or a message sent from an account that you do not follow or from an account
that is younger than 30 days.
So if you're being targeted for abuse by people who are just like creating accounts to harass
you, then your harasses have to go through these extra steps.
And this is one of the things, um, that I think fedivized clients as a whole could be doing
more of, um, there's, uh, this came to me in the, uh, last year, I think around the middle
of last year, um, was when the last big sort of blow up online happened around, um, uh,
people on the fedivist being harassed like sort of, um, uh, African Americans, for example,
I think we're making a lot of complaints.
I'm justifiably so, obviously, um, and the response, I think, from a lot of people was
to explain to them, well, this is just how federation works or, uh, we've got all of these
other problems to fix or whatever.
And I remember, sort of listening to or reading a lot of those conversations and thinking,
well, I wait a second, like this could be fixed, um, client side, not necessarily perfectly,
but we shouldn't be letting the, the perfect, um, be the enemy of the good, um, and then
if you are an open source developer, um, and you're interested in contributing, then there
are aspects around things like the project governance, um, the deliberately release processes
that I put in place, um, one of the things that I'm, uh, quite passionate about is making
sure that in every release, like everybody who's contributed, um, gets credited in
the release notes, in the announcement post, in the blog post about it as well, because
I think those are just good open source governance, um, practices to follow.
Yes, absolutely.
And that's of course one thing that gets so often gets overlooked is just the, the fact
that people, you know, people who may be, you know, contributing small parts, but of
course, these small parts are actually very essential.
And one of the benefits of open source, now you were talking there about people, contributing
and suggesting things, uh, for, I mean, we, we take it for granted to be honest, the,
the more technical users, we take it for granted that we'll look, we'll grab the source code,
uh, page or somewhere and go and put it in a blog reporter, a feature request, etc.
And let's just say this is for a more average dual blogs, who has discovered patchy,
patchy, uh, who, and they're saying, right, I want to, I want to suggest this, or I want
to help out what's the best way to contact you?
Um, through the, uh, the official, uh, packet master on dot social, uh, account, um, which
will be on the, the fediverse, um, there's also the, the team at packley dot app, uh, email
address, um, for people who are more technically minded than GitHub, uh, issues or GitHub discussions,
uh, also work.
I try not to funnel people down sort of one particular path.
I think you have to, uh, meet people who have got feedback wherever it is that they want
to try and provide that feedback.
And then it's kind of on me to bring that into whatever sort of like project management
types system I want to have to try and make sure that it, uh, it doesn't get lost, um,
which can be a whole, like, proper minute zone right.
Totally.
I mean, that's great to hear because I mean, so often, we, I mean, I'm so guilty of it
as well, uh, we, we can all be quite like that because we're just a super, well, that's
fine.
Raise an issue and good to have an, you know, you might as well say to people, go make
a samurai sword, some people that's, you know, it, it, it's just that you've just talked
gibberish to them.
Yeah.
A thing that's really important to keep in mind is that any time, uh, a user of your, of
your software is trying to give you, uh, feedback about some problem.
It's because they were trying to do something with your application and it didn't work for
them.
And they're probably going to be frustrated about that, trying to root them to different,
um, uh, systems to report that problem is not going to be helpful to them.
Um, and I think this is one of the differences.
And again, it's kind of a project, governance or like project philosophy type thing where
I, there is a difference, I think, between somebody who is working on our open source
project, um, like sort of purely as a hobbyist, like they've built something for themselves.
If other people use it, that's great, but they are still the primary audience perhaps.
And then at the other end of that continuum, you have like sort of the large open source,
um, projects that may have started as close source projects from different companies,
for example, um, but that have like a lot of that corporate backing and perhaps like dedicated
project managers and so on.
And then in between those two, you have like sort of the, what I'm trying to carve out
with the Pacty project is, um, deserves like no, the project is still like, it's an open
source project.
There's no paid developers, um, working on it, other things like that at the moment.
But this is a project that doesn't exist just to fulfill my needs for an Android
message and client.
I very deliberately want other people to use it and then to tell me when it doesn't work
for them so that it can be made better.
Is there a risk of, is there a risk of scope creep?
If you're building an application, which is intended to meet the needs of the end user.
Now, please don't misunderstand me.
I work in software.
I'm not, I'm a developer by like historical trade, but I don't develop at the moment,
but I'm definitely the user of a, of a service.
And I'm very demanding individual.
So how, how would you cope with, with that and avoid scope creep?
Um, I think it's a combination of prioritization and then having an idea, um,
both at the back of my mind and also it's public on GitHub, um, of what the sort of
medium to long term plan is for some features.
So when you asked earlier about, um, why should somebody choose, uh,
packly, for example, there are also like people who, uh,
probably shouldn't choose it at the moment.
So for example, if you're, um, if you're primary fediverse server is, um,
one that is not compatible with a master and API in many cases or has built
additional features on top of that, then pat it at the moment.
It supports a few of them that I've sort of bolted on here and there.
But the plans for making it more, um, cross server compatible are one or two,
like sort of major releases out.
And so if somebody comes to me and says, oh, I really wished you supported, uh,
reactions on posts, which some other client taps you do.
Um, I'm going to, uh, take that feedback.
It goes in the big pile of things to look at when the work to support other servers
starts, but unless there's something that indicates that suddenly become a big
priority, uh, for people, then it sort of, it will wait until that.
Um, another area would be if you are looking for a fediverse client that works
very well on large devices, so like foldables or tablets, um, things like that.
The UI for packet at the moment is pretty much targeted apps, sort of typical
phone size devices.
And again, I've got, uh, plans to change that, um, and that's in the, sort of
the long term project plan that's online, but, uh, that helps me sort of keep
the scope.
So maybe a little bit tighter, because I know that some of these things are going to
sort of push off to the future.
Um, and then other stuff, when I'm prioritizing work, uh, to implement, it's,
I've got a sort of a hierarchy of urgency for some of these things.
So obviously like any, anything that's a crashing bug, um, under common
circumstances goes to the sort of top of the list.
Um, then in terms of features, it's any, uh, feedback I get from people who've
got accessibility needs, um, but particular requirements, because I think that,
that is like sort of very important.
Um, and then it is a mix of, um, things that I want to fix, because just
being deeply embedded in the code, I know where all the problems are.
And that can be sort of very frustrating, because you just want to fix all of
them as soon as possible.
Um, I've also got ideas for features, uh, that I want to see and feature requests,
um, from other people.
And I try and balance those based on, uh, the feedback that I get about those
feature requests, um, if it's a number of people asking for it, then that'll sort
of bump it up the list, um, but things like, like Packley is never going to be a,
um, ah, what was it?
Uh, I think JWZ has a quote about, um, all programs eventually evolve to the
point where they can send email.
And I'm, Packley, Packley is not ever going to evolve, um, to that point.
For example, I'm quite happy to hear that personally.
Yeah.
Um, um, but there are these things around eventually support for other
servers, support for other types of devices and display sizes and things like
that.
To make it a better experience, um, for users, uh, because that ultimately is
the, is the, the, the driving force, I think, um, and the, the reason why I
spend, like sort of a lot of time on this, like, is incredibly satisfying to
get feedback from somebody and now some new feature, uh, that you've launched
or where they've maybe requested this, like, sort of six months ago, and
it's gone on the back burner because I've had other things to, to work on.
But to then be able to turn around and deliver it to them and say, this
exists because you highlighted this requirement that I hadn't even thought
of, um, I think is, is really gratifying for them and getting the, the
feedback from them when it works for them is very gratifying for me as well.
Right.
Um, you used the word earlier.
You mentioned the word hobby, um, it's, it's listening to you talking
about this and the passion with which you're describing so many of the
different facets of, of the, of the project.
This is clearly not a hobby for you.
This is a, this is a serious development project.
Presumably, this is something that is only limited and constrained by your
own capacity.
So is there any, anywhere, any particular areas of the project, either in
terms of development or any other of the non functional areas that could
benefit from more expertise?
Absolutely.
Um, I think the, the overall UI, um, and consistency around it, um, is
something that I sort of keep bumping into and discovering that bits of the
code have re-implemented the same thing like sort of 15 different times.
Um, and just to be very clear, like because this is a, a fork, I don't want that
to come across as like sort of throwing shade on the, uh, the previous
history of the goat, right?
So the, the Tusky project, um, I think was started in 2018, um, and a lot of
how Android apps are developed has changed a lot since then.
Um, and so like sort of design decisions and things, um, and implementation
decisions that were made back then aren't necessarily the right way to do
things now, but that doesn't mean they weren't the right decision.
Back then and with the, the constraints, uh, that they were operating under.
Um, there is, uh, definitely work to be done around improving the, uh, the
testability, I would say, of the code and the level of, um, certainty, um,
around the quality, uh, of each release and I sort of making sure that, uh,
regressions don't happen.
Um, I'm going to actually, I'm going to use that as an opportunity to maybe
sort of segue into, uh, something slightly different.
So, uh, one of the things that the project does or is, is under the umbrella
of the, uh, nivenly foundation, um, which is, um, and at the moment, U.S.
place organization, um, that exists to support, uh, different open source
projects. And one of the things that I want to be able to do through them is
offer, uh, internships on the project paid to people who would otherwise
maybe want to be able to contribute to open source, but are not financially,
uh, able to and be able to work with the nivenly people to provide, uh,
grants for that work.
So what, and one of the projects that I've got in mind, which is,
why this just occurred to me is the idea of writing a lot of screenshot tests
for the app. If that's something, if that's something you're familiar with.
So the idea that, um, you start the app, you drive the UI into a particular
state and then you take a screenshot of what it looks like in that state.
And then future code changes, um, run those same tests and you take the same
screenshots. And as long as they are pixel for pixel identical,
then you know that you have inadvertently broken the UI. Okay.
But, um, if they are different, then you know that you have it inadvertently
made a change that has caused some UI elements to move or a dialogue box that
should have popped up and no longer popping up, um, or, um, I don't know, uh,
in a mode G that should have appeared in somebody's, uh, name on the screen,
is up, is appearing as the short code instead of the emoji.
And then you get to scratch your head and think, oh, okay, what's if I broken
now? Um, and of course, like trying to do that through, um, regular, like,
sort of unit or end to end testing, um, is very complex, um, and
quite sort of tricky to do. Um, and, but it's, it's important to have those sorts
of controls in place so that every time you push out the new BC release or whatever
you don't get users, banging on your door, saying, oh, wait a second, this
thing that used to work is stopped working, um, because it's incredibly
embarrassing when that happens. Yeah. How, how automated is your, um, your
testing suite? Um, so the testing suite itself, uh, is pretty automated and
covers most of the, um, the side of, do we get data from a remote server?
Uh, and then mangle it in the appropriate way and does it end up in the
local database and ends up in the expected format. And if the, um, it's a
bookmark function is called, for example, does that result in a network call
out to the, the other end. Um, but that sort of tests the intent of the
code and not how things can necessarily appear on the screen. So if that book
not called fails, you kind of really want to make sure, well, does the
error message pop up on the screen for the user? Do the, with the little
retry button so that they can retry it and so on. And while you can write a
lot of code to try and do that, the simplest way to do it that I know of,
um, that gives you the most bang a few back in terms of effort to expanded
versus useful result out of it is, uh, screenshot tests, because that,
it, it tells you something is very definitely gone wrong here. Um,
even if you don't know what the cause of that is.
Very interesting, very choosing indeed. Um, you mentioned earlier about the
Nivellany Foundation. I was going to ask you about that. But now I don't
have to. But you mentioned on the Nivellany website that packly is an
application, which we've already spoken about. Yeah. Um, but also a
spice to be an association. What does, what does that mean exactly? Um,
so funny enough, I have a PR out at the moment that might actually change that
language. So when I first started the project, um, and so this, and this was
before coming under the umbrella of the Nivellany Foundation, um, one of the
ideas that I had in my head, uh, was to start, um, a legal entity that could do
things like properly, uh, own a copyright, the, um, the resources acquired by
the project. So things like the domain name, um, and things like that. And
then could operate as a cooperative with members. And then the membership fees
would be what would fund things like, um, grants to provide internships.
For example, I was talking about earlier. Um, in the very early days of the
projects, I then contacted a number of organizations that also provide, um,
those that sort of functionality. So there was the pre-sortware foundation, um,
I'd benefit to get their name software freedom conservancy. I think, um,
SFC, yeah, um, and, uh, Nivellany, um, on all of those three, um, sort of
talkative, then Nivellany seemed to be, uh, the best fit for the project,
because they're already, um, very active on the, the Fediverse and, um,
providing, uh, funding for the, uh, the Hacquidum, uh, project, which is a,
method and, uh, server. And so there was sort of this natural fits there. They also, um,
have the same, like sort of, uh, cooperative principles. So the idea is that you,
you pay to become a member and then membership grants you the ability to vote on, uh,
different proposals on, say, how that money might be spent. And since that was one of the things
I wanted to be able to, uh, to do coming under the Nivellany foundation meant that I'd have to
start my own association to do that. And all of the hassle that that would take,
including interest and finding a second person to be the sort of, uh,
co-chair on the board, um, and things like that, I could instead slot under, um,
that Nivellany umbrella and let them, uh, deal with that side of things instead. And then,
this also exposes you to like a larger user base. Um, uh, people who've got more experience with,
governance and non-profits, uh, and things like that as well. So this expands the number of people
that you can, uh, get advice from as well, which is sort of super important. I think a common
failure mode in this, of course, is to, um, be sort of quite good in one, uh, area of expertise.
I think that that just then translates into, oh, well, I must be good at all of this other stuff
as well, right? And of course, that's not the case. I don't really know the first thing about
running an association or a non-profit or whatever. So, um, rather than discover all myriad ways,
it's possible to, um, uh, get that wrong. It's much better to believe that to people who know more
about this than I do. Yeah. We see that a lot in, in some, uh, open, open source and open cultural
organizations, uh, there's an event that happens on a mostly yearly basis called OgCamp,
uh, that was imaged the last year, um, which is like, uh, an unconference of, it's, it's a,
it's a geeks get together. That's what it is. Um, but a lot of the, uh, the, the, the legal
sonny of it has been given to a organization. I've completely forgotten the name of, um, right,
um, no, uh, no, Simon's group, uh, oh, um, yeah, it's going from me. I can't remember the name of it,
but they, they, they look after the, um, they don't, they look, yeah, they basically look after the
finances and the legal and the, um, the, I suppose the boring stuff, right? There isn't actually
organizing or arranging an event. The stuff that has to be considered that W really wants to do
is being, being given to this other organization to take care of. Um, governance is a service,
if you're like, yeah, I'm back to back in the day, back in, um, 1999, I think it was myself and
three others, um, organized the first European BSD conference, um, with like no experience of
organizing conferences, um, at all, and we just figured, right, well, how hard can it be? It turns out
damn hard. Um, so that was sort of, sort of quite eye opening. Uh, and then in the years, since
now, I think there are a lot of sort of dedicated organization that does exactly like sort of what
you've just said, um, right. But for that, um, yeah, exactly. Uh, public software CIC is the organization,
yep, um, that was behind, uh, the PC underpin dog camp last year. Well, that's them for a few years.
So now, totally understand. And if it takes some of the pressure away from you as, as, can I say,
project lead? Uh, you can. Um, the term I'm trying to use, um, is sort of project steward, um,
because I feel like that conveys the idea that this is a, a role that in the future is hopefully
going to get handed off to somebody else, um, understood. If I'm still doing this in like sort of
five or six years time, then maybe my idea is about how this works with the size of the fediverse
or whatever turn out to be wrong. Um, in many ways, like this is an experiment, um, to, to see what
happens there. Understood. Yeah. Hack up, public radio works in a very, very similar way. We don't have
project leaders or administrators. We have janitors. Yep. They just basically keep the floors clean.
And I don't mean that in the two wrong countries, huh? They do, they, they are effectively running the
show. Yep. Um, but yeah, they want to be known as genesis and I completely respect that.
Yes. Now, just before we actually move on there, you spoke about, uh, spoke about the financial
and things they are just if anyone's listening. And again, I don't know why, but I seem to be kind of
a voice of the non geek tonight, which is not me at all normally. I actually don't get why I'm doing
this, but let's just say, I mean, there's, there's plenty of times where certainly somebody that's,
you know, has coding ability can get involved with things or as graphical ability or as experience
with, but if somebody's like, uh, again, we're just going to see average Joe and they want to say,
I'd like to contribute. I'm, I'm not going to contribute much, uh, as far as expertise, but can I
set up a donation scheme or anything like micropayments or give a one off? Do you accept that?
So if somebody was wanted to do that, um, then the way to do that would be to, uh, join
nivenly as a member. Um, one of the things that I'm sort of trying to avoid is there's certainly,
there's certainly space in like, in open source projects for those projects that were, um, it is
like, say, uh, a solo developer and they're operating under the sort of the tip jar type model,
right? So whether that's Patreon or co-fi, I know, I'm never sure if that's supposed to be
pronounced co-fire, or is it really coffee? I think so. I've always assumed coffee. Yeah. Yeah.
And things like that, where the understanding is that that money is going direct to the developer
to spend however they want, right? And for, like, smaller projects, like, that's absolutely,
absolutely fine. Like, no couples about that, um, at all. But with, uh, particularly,
sort of what I'm trying to do with, um, patty is, I don't want people to feel like they just throw
many into these, uh, at a developer who's going to sort of spend it however they want. I would
might rather that they use that money to become a member of Nivellany because that then
gives them, if they choose to use it, some control over the project as well. By which I mean, um,
wait, I've got my, uh, intern RFP document up here at the moment, um, which I'm sort of drafting.
And then when that goes out, um, the packet membership will be able to, sorry, the
Nivellany membership will be able to review that. Ask questions, provide feedback. Um, it will
eventually go up for sort of some sort of vote as to whether or not the membership wants to
approve to spend Nivellany funds on that. And that's the sort of direction, um, sort of, I
personally would like to see these types of open source projects go down where you don't have,
um, like a large, um, company that's making the decisions about some of the stuff but it's
like still expecting, um, open source contributions or maybe funding or whatever, but that if you are
going to provide funding, then that provides you with, uh, more or say in the project as well.
And now that say doesn't go as far as, for example, paying money to get a particular feature
implemented. For example, like I don't think that's a route I would particularly want the,
the project to go down. Um, but then again, um, ultimately that's not a decision for me to make.
That's, that will be a decision for the Nivellany membership, uh, to make something like some
hypothetical future. The Nivellany member was to, uh, propose that, uh, Nivellany spend some amount
of money on hiring or, or paying it available to work on, like say, some specific feature. Um,
then I get to sort of talk of that about that proposal and maybe say well, then I think it's a
good or a bad idea and vote in the same way as every other member. Um, and this is the, um, the,
the cooperative model. And so there are a few master and service providers that operate under
the same model. There's one in Canada, for example, um, co-social.ca where you pay to be a member of
the server. Um, and then that grant you some sort of rights and responsibilities, uh, as well.
Okay. That obviously is from, from your perspective, as project steward, by granting,
delegating, I suppose, um, control of the project to the members of the Nivellany foundation.
Is there not a risk or even a fear perhaps that the rug could be pulled out from under your feet
that you could lose, um, either control of or creative or, um, aspirational control of the project?
Yeah, absolutely. But this, this I think comes back to, um, what I was saying earlier about,
like sort of deliberately using the term steward and that I ideally want this to be a, like, not a
super, super long term thing. Um, the, the code that started the project, only some of it was
written by me. A lot of it was written by other people on the, uh, the Tusky project who contributed
over the years. Um, and as and when, uh, we're at the point where there are other people who are
contributing and other people who are capable of stewarding the project through and sort of
I reached the point where, um, I'm able to move on, uh, to something new. Then, uh,
the, the half life, I guess, is the code that I've written will probably shrink down a little bit
as well. Um, I think it's, uh, something I see a lot sometimes from, uh, more,
uh, junior developers in open source is this idea that their sense of self or their sense of
self was is, is deeply tied to their code or the quantity of code or how quickly their code is
um, admitted into a project or whatever. And I very firmly believe like that is not the case.
You aren't, you are not your code. Um, and attitudes like that I think makes things like sort of code
review. Um, so much easier and can sort of reduce the, um, the, I was going to say fights
was maybe the wrong word. Um, the arguments that sometimes happen when I know somebody,
somebody who has, has written some feature and somebody else comes along in six months time and says,
oh, I actually know there's a faster, better, safer, more bug free implementation of this.
Here it is. Um, and I, you know, you know, good, well run project, somebody's going to look at that
and go, great. Thank you very much for your contribution. But what often happens is,
whoever the original sort of that code, can you so then come back and go, oh no, wait a second,
like they're saying this thing that I did six months ago was terrible and needs to be replaced.
It's like, oh, I feel personally attacked by that. It's like, no, no, no. It's like, I'm the first
person to admit that code that I wrote six months ago is probably terrible and needs to be replaced.
But it worked. Um, at the time. And so, yeah, I think there is, there is a real danger that people
can become too attached to this. And then that results in a lot of the, um, the problems that we see
in open source projects that don't think about stuff like this or like governance issues and things
from the very get go. Um, I think that's, yeah, that's a, that's a common failure mode.
Something that I was aware of and something I wanted to very deliberately avoid, um, with this project.
Yeah, understood. Yeah, totally. And I think it's, I think we've all experienced it, especially when,
you know, with, uh, I mean, uh, in the past, I've reached out and I've said, you know, I've
not criticized. I've just said, I've been using this. I've done a few times on for tux chant reviews.
I've been using this. This could maybe do with them proving that this experience that I had,
not intending to slate them, just trying to give them, you know, constructive criticism or
say, but I put a feedback to say, have it this. And of course, you get the more or less ranty email
it's the card man that kind of screw you guys. I'm going home kind of mentality. You know,
it's like, oh, no, it wasn't meant to insult you. It was a bit to try and make your project better.
And I think you said it earlier, you know, it says somebody who's taken the time to actually give
you feedback, then the reason is because they've tried using it and it's not behaving in the way
they were thinking it should or expecting it to. Yep. Yeah, for sure. I think, um, one of the,
one of the things that I try and do, um, I don't know if I'm sort of not perfect and probably
fairly this many times, but is if I'm getting feedback from a user of the app, like whether it's
feedback or Macedon or they've reported a GitHub issue or they send an email or whatever.
The first thing I try and remember to do is like, if it's a bug that they're reporting is apologize.
Because it sort of, it's almost like it, it almost decouples me from the code a little bit.
Hopefully makes them realize that their feedback is appreciated and that this isn't about to be
like sort of combative interaction. And then take it from there. I saw this, I mentioned earlier about
the, um, a lot of the conversations that were happening around, uh, people being harassed
around the middle of last year. And I saw this a lot in the conversations there where people were
applying with lots of technical reasons about why this was still happening or how difficult it was
to solve the problem, um, or, oh, I don't even see that as being a problem or whatever.
But it was very, very rare for me to ever see, um, anybody in those interactions, like whether
it is, whether it was somebody from Macedon, GMBH, um, or a server operator or, um, somebody responsible
for one of the other server projects, starting by apologizing to the people that were reporting
the harassment. It was all very much straight into the technical side of, oh, well, you just don't
understand how federation works or it would be really difficult to fix this or whatever. I like
just remember watching these interactions and scratching my head slowly and thinking like this could
be so much better. Um, but it's, when it's people arguing backwards and forwards across the screen,
it's really easy to fall into that mode of, that mode of thinking, um, and forget that it is
somebody on the other side of the screen who has been affected by this. Yeah, yeah.
Um, I suppose if, if some, the way to look at it is, if somebody is willing to approach you
and say, I think this could be approved by doing it this way, more than anything else, it demonstrates,
hopefully demonstrates that that person cares enough about your product, they want to help improve it.
Oh, I'm, yeah, absolutely. Um, I mean, like everyone happy, everyone happy user is still the user
at the end of the day, I guess. Um, and certainly with some of those interactions, I found it,
um, very rewarding to them, I actually probably have a conversation with them about,
okay, well, you're asking for this particular thing, but if we do that, then I can like maybe
ratloft, like, well, here are three or four consequences of that that maybe you haven't thought of
that we would need to mitigate in some way. So maybe we can have a bit of a pack and force about
how we might actually achieve what it is that you want to achieve with that necessarily achieving
it in the way that you've suggested that we achieve it. Yeah, what they need, not what they want.
Yeah. Yeah, exactly. And, um, I sort of found that to be, to be very helpful as well. Of course,
sometimes some people just want to fire, if we, fire and forget, um, a request in or whatever,
and don't have the time to, uh, fill up or contribute further or whatever. And then I kind of
looping back to what you're asking earlier about things like sort of prioritization. That's the
sort of thing that might, depending on the nature of the problem, deprioritize it a little bit,
um, because I'm then coming away from that interaction with a bit of a sense of, well,
if it, if it wasn't that important for you, it's not necessarily going to be that important,
um, for me to fix, especially if it's a sort of a, a throwaway, or comes across perhaps,
there's a bit of a throwaway suggestion. But like anything else, it's a, it's a bit of a balance
to be found. Yeah, I understand that. You've, um, mentioned a few times, Nick, that, uh,
Packley is, is a fork of, of Tuskegee. Yep. Um, I wanted to ask you, uh, the status of that is,
is Packley now, um, a completely distinct co-base as in a hard fork of that project,
or is there still some form of upstream downstream, downstream collaboration between
Packley and Tuskegee? So it's now effectively a hard fork, just because the co-base has diverged,
um, various, very significantly. Um, some of that, some of that is bug fixes. Um, some of that is,
features, um, that have either been implemented differently or implemented, or are going to be
implemented in different ways. Um, an example, a very recent example, um, might be one of the,
one of the future requests I've been getting is, uh, to have a different visibility for replies.
So in Packley and in Tuskegee, you can say, well, I'm posting, do I want to be posting,
like publicly or just to my followers or direct messages or whatever. Um, and there's been
requests to say, well, I want to be able to post publicly, but I want my replies to be unlisted.
Hmm. And I was doing a little bit of research into those requests and looking at what other,
uh, uh, Macedon clients do. Um, and most of them just give you like sort of a checkbox,
um, or a switch to say, I want my replies to be unlisted. A couple of them give you the ability to
say, no, I want my replies to be public or unlisted or only to my followers or direct messages.
And I was looking at that and thinking, well, well, I need to sort of truth table out kind of all
of these different options and see which ones actually make sense. And once I've gone through that
whole process, I realized that actually a single switch for unlisted, uh, is going to be both
the simplest thing to do. And I think the thing that matches up with actual user intent. So that's good.
Um, but in the course of doing that investigation, I discovered the Tuske, the Tuske project
has already implemented this feature. Um, but they have done it with a menu of you can choose
public unlisted, follows only in direct. And having gone through that process and asked for feedback
online, um, about what makes sense. My conclusion from that is the approach of things like
Fedelab and the Moshodon project of just having a single checkbox is the correct one. And so that's
what I will do. And things like that will mean just again, mean that the code base diverges further
and further and further. Um, that's not to say, um, if the Tuske project would ever to, uh,
want any assistance bringing some of the features that Packley has over into, um, Tuske,
like I'm always I sort of very happy to, uh, you provide feedback and sort of knowledge about that
because I think overall, like I guess, um, it improves the overall, I sort of health of the ecosystem.
Um, I talked about the, the anti harassment controls earlier. Um, and at the moment, Packley is the
only client that I'm aware of that has anything like that. I would be overjoyed if one or more other
clients decided that they wanted to implement the same thing. They probably wouldn't be able to do
it in exactly the same way. But I would very happily spend time, um, with any of the other client
developers about, okay, this is why I did it this way. Packley is the problems that I had. This
is some things that you might want to consider and so on because that sort of feature shouldn't be
something that she's locked away, um, in a single client. I love the fact that your, um,
your approach to this is so not a, this is my boy, you can't play with it. This is very much, uh,
uh, an ongoing collaborative effort. I mean, the fact this is an open source project in,
you know, in an obvious home, right, means that people can go in and have a look at the code.
And if they wanted to reuse it for any purpose, subject to license, of course,
they could take a feature out of Packley and put it into Fedelaab or put it into, um,
into Tuskegee, I presume. Yep. Yeah, absolutely. Um, I mean, so package, uh, KPL3 license, um,
as I think most of the other open source clients out there, um, I don't, I'm not aware of any commercial
ones for Android. There are a few commercial ones, I think, for, uh, iOS, um, but that's about it.
And I mean, you're coming about sort of holding onto the ball too tightly. Um, I think I think
about quite often is I'm only sort of where I am both, like, sort of physically in Switzerland
and the position that I'm in through the sort of very unlikely chain of circumstances, a lot of
which has involved other people being prepared to spend a lot of their time and energy teaching me
different things. And I think you have to find ways to sort of pay that forward, um, whether
like sort of teaching other people, um, online, offline, making your code available, things like that.
Yeah, amazing. Um, Kaby, do you go any, uh, any further questions?
I don't think so. If, uh, I mean, I had a few, I went ahead and then Nick was the answer in
them. I said, so you've done a really good job there. Uh, I'm assuming you're not using some
mind protege, isn't there? But no, the only one thing I think that I was, I had it in the back of
my head, but, uh, I'll say it now that I've said, I've said this much was, would, are you going to
consider, maybe you do an I just don't know about this. Do you offer like a pre-release
for a tester? Yes. Um, so there is a very intrapackly called, um, we're studying it on
originality, uh, packly current. Um, so that is also in the, it's in the Google Play Store. Um,
you can also download it from the GitHub, uh, releases page or if somebody uses, um, uh, what's
called, um, there's an app called obtaining them, which makes it very easy to install these, um, as
well, that tends to get releases every three to four days, um, with either like sort of pre-releases
of new features or if some library dependency has been bumped, um, and it works for me, but I need
to make sure it works for, uh, for everybody else. Um, for people that use eftroid, um, as their
repository, unfortunately it's not available there just because of how eftroid builds things, um,
is not really feasible to, uh, to make that happen. But on, um, on the packly.app website, um,
at the top there are, uh, there's a link to the installation instructions and somebody there
can go and from there they can see how to install packly and packly current and you can install
both of them side by side. So if packly currently starts cracking, that's my actual next question.
I was going to see candy runs side by side. So you've got something to fall back to, um,
and one of the features that came out in the, uh, the release just before this one. So,
was it two 11 or two 12 one on, um, there's now experimental support for exporting and then being
able to import your, um, uh, different preference settings from within packly. So if something happens
for example and, uh, packly current starts crashing as long as you've got a reasonably up-to-date
export of your settings, then, uh, it is now much less painful, um, to, uh, before you had to
sort of relocate and then set everything up the way that you wanted. Now you just have to relocate
in and re-import the settings. Now does that support cross-version, uh,
import export? So if you, if you have, so for example, I've got a packly on my phone. Yep.
Um, if I want to do install packly current, could I then export my settings from packly and import
them into packly current? Yes. Um, the, so the export file contains a version number. And so,
as long as the version number is, uh, lower or equal to a version number that, that version of
packly supports, they know, then it will work. And that's specific to the file format, not the
version of packly. I understand that. So that, I'll buy it, go check. Yeah. So that should,
right. So as long as nothing, nothing's changed in the structure, you should be able to just
light back and forth. Yes. What it, what it doesn't do is it doesn't export your account credentials.
Because I don't know enough about how to do that securely and safely on Android.
So I wasn't sort of going to text that particular large box. So you still have to log in with
all of your accounts. Um, but then once you've done that, you can then just go into, um, there's a,
there's a section in the preferences called lab preferences and you jump into there. And then
there's a whole bunch of stuff in there that's, um, currently sort of baking and waiting for you
to use a feedback. Um, so there's features in there like, uh, experimental support for markdown
or being able to reverse your timeline. So instead of scrolling up to seeing your stuff,
you can scroll down. Got it. Okay. Um, one more question for me. And then we'll probably wrap up.
Right. Um, I recently replaced my phone. Yep. And because I am getting old and I have holes
in my head that leak very relevant, a recent information, I cannot recall whether I had to
re-log into everything and set everything up again or whether it went across with the phone.
So I'll ask you directly. Does Packley support the Android configuration backup thing through
Google Drive, the automatic one? As of a version or two ago. Yes. And that does restore your account
credentials because the Android backup stuff is set up so that it is encrypted, you know,
in a trustworthy way. So then yes, you can migrate from one device to another. Um,
they're in the sort of the normal Android way. Um, and that sure that's really that should just work.
If it doesn't send me a bug report. Well, I'll let you know in three years time if I was on my phone.
Uh, but either that works and I didn't notice because I took take a lot of things like that for
granted. Sometimes, no, it just worked. Yeah. Or I actually went through the pane of it and the
trauma of that have just blocked out. Right. So I can't remember either way.
You've got me. You've got matters. Now it's to which is to which version this came in. Um, oh
yeah. So, uh, 2.12, which was the version released at the end of people. I don't know because I
got my new phone in March. Uh, okay. Right. And in which case, no, it wouldn't have done.
No, but as of as of the 2.12 release, um, at the end of April, that's now all gets backed up and
restored. If you, if you have a Google account on the, on the device. Yeah. See, that's a big
if I like to make my life, Missouri, you know, install everything individually again and read stock,
read, read login, of course. Yes. Of course. A lot, a lot of our listeners will be
very much of the, I don't want anything to do with the Google, um, camp. So it's unlikely they
will have any of the Google Play services, let alone have a Google account, uh, which I get.
It works both sometimes difficult as an Android software developer to sort of walk that line
because it does make some things a lot more complicated or you end up having to drop or limit
um, some features. So one of one of the things that Patty can do, for example, is you're supposed to,
um, when you are writing a post, you can write it in whatever language you like.
But it is still up to you to sort of set the, the toggle when you're posting this, I'm posting
this in English or German or French or whatever. And a feature that I put in Patty quite a while back
will try and run language detection on, uh, the text that you've written. And it will warn you,
if it looks like say you said you've written in German, maybe because you were applying to somebody
in German, who are originally writing German, um, but you've actually written it in English. And it
will prompt you and say like, do you want to change the, uh, the language of the post that you've
written into to say actually it's in English. And on Google devices with the Google Play Services,
you get the Google machine learning stuff that tells you what language something is in, um, with a
higher degree of fidelity than you do just on sort of base Android devices. Um, and trying to sort
of juggle that feature and figure out what the correct thresholds were for different types of
devices was, was quite complex, but I didn't want to leave one particular group or another, um,
out when it came to implementing stuff like that. Yeah, I suppose trying to accommodate
everybody is, uh, is not easy. That is certainly more difficult on the Android ecosystem with the
range of different device sizes, um, and things like that. And that again, actually where taking
this is all most all the way back to the beginning where like screenshot tests are so useful,
because instead you can say, oh, I want to see what it looks like on a tablet. And on a device that's
yay big and a device that's much smaller, um, or is landscape or whatever. And it makes these sorts of
things a lot easier. I'm going to ask you one more question because you just prompted it by
when something you just said. Um, if you suddenly disappear, I will understand that I offended you.
Have you considered porting developing whichever for iOS? Um, very briefly, and then I realized that,
I just don't have the time. Um, it is something that I think is technically becoming
um, a lot more feasible, um, with how the, the language that is written in, which is Kotlin,
which is a sort of a descendant of Java. Yeah. Um, and the Kotlin project has made a lot of headway
on multi-platform support. Um, but a lot of the patty code base was written, um, they inherited
through the touchy code base was written at a time where having a very clear separation of concerns
between like your network data model and your database data model and your user interface data
model and how data flows between all of those and how, um, user interactions on the device,
those actions flow back down. Of course, things that happen. Um, best practices now is to keep all of
that very clearly separated. Um, and a lot of the patty code base at the moment because of where
it's come from doesn't do that. Right. One of my ongoing bits of refactoring work is to improve
that situation. Um, but that's what they get slotted in amongst bug fixes and new features,
and things like that. And these are one of the things where I've almost like sort of, um,
trace myself by my own petard a little bit with this idea of,
releases happen on a monthly basis. This does mean that anything that takes more than a month of
work to work on has to get slotted in amongst everything else and can, when your context switching
between lots of things potentially can then take a lot longer as well. Um, that again is why
things like this, um, idea for, um, internship projects. I'm looking very much at things that are
uh, self-contained, tightly scoped, don't necessarily interact too much with the
the rest of the code so that somebody can go off and work on them. Um, uh, but yes, at the moment, um,
iOS support from me, certainly is not something that's going to happen any time soon. However,
if anybody lives into this, has it on Android and also has a iPhone or an iPad or whatever
thing? I would really like this one here. I'm not going to turn, turn down contributions that make
that, uh, happen or bring us close to that goal. Absolutely, because it also improves the overall
quality of the code. Yeah, understood. Yep. Great. Right. Before we sign off, actually, I was just
going to see that the one last thing we always do is if people want to get in touch with your
self, Nick, what is the best way to do it? Um, so if they want to talk about anything other than
badly, then on Macedon, then the easiest way to do it is just to, uh, message me on there. Um,
either a private message or like public on the thread that I'm happy to discuss a lot of stuff
in public. So that is just, uh, at Nick Clayton, uh, at Macedon. social, um, and the Nick is
spelled NIK because when I was growing up, that's how many lessons you could get on the arcade
high school tables. Oh, which game you've got to tell us now? Oh, good. Um, so many ghosts and goblins
kicked my backside reliably and regularly when I was growing up. Um, and then of course, uh, bubble,
bubble. Oh, yeah. Words were just, yeah, fantastic. Um, and then if it's stuff, uh, about
packing, then my preference is, uh, send it to the at the packley at Macedon. social
account just because, um, I'm much more likely to then remember to copy that into like different
project management systems. Um, and stuff, if it is something, uh, that they want to talk about,
uh, privately or like a security issue or something like that, um, then an email to team at
packley.app, uh, or reach made well. Thank you so much for taking your time to come on and
thank you for all the work you're doing on packley. Well, thank you very much. Thank you both for
the, uh, the questions. I've really enjoyed this. Oh, good. Glad to hear it. I, I've, I've been using
packley ever since we reviewed it on tux tram. So one 14, we should back in August last year.
Um, I was a, what was I using at the time? I was using husky at the time, which I think is also a
dusky for. Yep. Um, and I, I really enjoyed husky, but packley for me, it, it ticked just a couple more
boxes of the way that I wanted to use, uh, a Macedon client. And so that's the reason why I stuck with
it. And it, yeah, it's, it's a, it's a really amazing piece of, uh, piece of software. So thank you
from me. Oh, thank you very much. Um, I mean, I can't emphasize enough though. Like a lot of that is
the foundation that it's, that it's built on. And then many other people that, um, have contributed
over the years. Um, but yeah, there is a lot in there as well where I'm looking at it. And I'm just
going, this feature should exist. Or we should be able to do this other thing. Um, I think that's
maybe a, a failure of the master of an ecosystem. I think perhaps is there is a, um, a mindset of
a lot of the stuff should only be done in the server. And then the client should be as dumb as
possible. Um, and I get the sense, or I get, I feel like I understand why the Macedon organization
would sort of want that level of control. But at the same time, it also makes it more difficult
for clients, I think, to, uh, innovate in this space. Um, and with things like the, the anti-RS
network, for example, um, that really was like something where I was looking at this and going,
yeah, like clients could do better about this. We don't need to wait for the servers to implement
particular features. Um, and then of course, it works on other servers as well, like
go to social or pluroma or, uh, cameo, or, um, uh, what's the other one? Um, Sharky, I think I'm
thinking of awesome. Well, thank you, Nick. Very, very, very, thank you. It's appreciate your time.
Um, it's been really, really good. Yeah, I, I, I, I, I, it's, it's always nice to be able to sort of
talk about, uh, a lot of the stuff with other people, like so much, so much of like coding is,
they're not necessarily a solitary activity, but you don't get to, um, talk about the, the meaning
of the reasons for off of this, um, like it would be, um, I'm not going to start talking about the
philosophy of some of the stuff in the release loads. For example, um, yeah, but I'm hoping that
these ideas will resonate with, uh, at least some of the audience. Um, some of you may be,
even then, uh, might feel like they want to contribute. Yeah, so, yeah, thank you very much for joining us
and tune in to model for another exciting episode of Hacker, public radio, you have been listening
to Hacker, public radio at Hacker, public radio does work. Today's show was contributed by a
HBR listener like yourself. If you ever thought of recording podcasts, you click on our
contribute link to find out how easy it really is. Hosting for HBR has been kindly provided by
an honesthost.com, the internet archive and rsync.net. On the Sadois stages, today's show is
released on their creative commons, attribution, 4.0 international license.